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EXECUTIVE  SUMMARY 


Seven  technologies  and  six  techniques  were  developed  and/or  integrated  for  the  Synthetic  Theater 
of  War  -  Europe  (STOW-E)  as  a  stepping  stone  on  the  path  to  STOW97.  Each  technology  and  tech¬ 
nique  is  summarized  below  and  illustrated  in  table  I  with  an  evaluation  of  its  necessity  and  its  ade¬ 
quacy  for  STOW97. 

Table  I.  Technologies  and  techniques  evaluation. 


TECHNOLOGIES 

Aggregation/Deaggregation 

This  technology  was  necessary  for  STOW-E  to  link  a  constructive  model,  such  as  the  Battalion/ 
Brigade  Battle  Simulation  (BBS),  that  uses  icons  representing  multiple  individual  entities,  with  a 
virtual  model,  such  as  Simulation  Network  (SIMNET)  or  Distributed  Interactive  Simulation  (DIS) 
technologies,  where  all  units  are  represented  as  individual  entities. 

To  bridge  the  gap  between  the  constructive  simulation  and  the  virtual  simulators,  an  aggregation/ 
deaggregation  technology  was  created  by  integrating  the  Advanced  Interface  Unit  (AIU)  and  the 
Semi-Automated  Forces  (SAF)  engine.  The  AIU  provided  the  interfaces  between  the  BBS  simula¬ 
tion  and  the  SIMNET  simulators,  performed  translation  between  DIS  and  SIMNET  protocols,  per¬ 
formed  dead  reckoning  of  DIS  entities,  and  provided  necessary  functionality  that  was  missing  in  the 
SAF.  The  SAF  engine  performed  the  actual  modeling  of  the  deaggregated  BBS  entities  as  individual 
vehicles,  and  provided  several  basic  maneuver  and  combat  support  functions. 
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The  goal  of  the  aggregation/deaggregation  project  for  STOW-E  was  to  implement  the  BBS/SIM- 
NET  interface  into  an  operational  exercise  and  include  interactivity  with  the  Combat  Maneuver 
Training  Center  (CMTC)  Live  Instrumented  Range,  thus  providing  the  enabling  technologies  for 
aggregate-level  constructive  wargaming  systems  (BBS),  individual  virtual  simulators  (SIMNET), 
and  individual  live  combatants  (CMTC  -  Instrumentation  System  [CMTC-IS])  to  interact  in  a  joint 
training  exercise. 

Achievements  during  STOW-E  include  many  successful  interactions  between  the  constructive, 
virtual,  and  live  domains.  BBS  tank  platoons  engaged  and  destroyed  SIMNET  tank  simulators,  and 
fired  on  CMTC-IS  real  tanks.  BBS  artillery  missions  were  successfully  fired  and  BBS  minefields 
were  emplaced.  Both  were  effective  against  SIMNET  tank  simulators.  SIMNET  tank  simulators 
were  able  to  pull  up  next  to  BBS  fuel  tankers  and  cargo  trucks,  and  receive  the  appropriate  fuel  and 
ammunition  resupply.  BBS  aircraft  (fixed  and  rotary  wing)  engaged  and  destroyed  SIMNET  tank 
simulators.  BBS  air  defense  vehicles  engaged  and  destroyed  Ft.  Rucker  helicopter  simulators  and 
the  Grafenwoehr  Falcon  Star  (F-16)  simulator.  SIMNET  tank  simulators  and  Ft.  Rucker  helicopter 
simulators  saw  BBS  aggregate  units  as  individual  vehicles,  and  engaged  and  destroyed  BBS  individ¬ 
ual  vehicles.  The  Falcon  Star  simulator  engaged  and  destroyed  BBS  vehicles,  and  CMTC-IS  fired 
artillery  and  destroyed  BBS  vehicles. 

There  were  several  problems  detected  during  STOW-E.  The  BBS/AIU  hash  table  filled  up  after 
2048  entity  entries  causing  the  process  to  stop.  There  were  problems  with  SAF  movements  involv¬ 
ing  travel — on  road,  water  hazards,  and  tree  canopies,  and  occasionally  aircraft  would  wander  off 
course.  SAF  minefield  markers  looked  different  on  different  Stealths,  and  the  orientation  of  breach 
markers  was  wrong.  There  were  problems  with  the  SAF  terrain  database  where  entities  hit  steep, 
vertical  walls  and  got  stuck,  and  then  started  flipping  around.  There  was  no  control  over  target 
acquisition;  therefore,  as  soon  as  line  of  sight  was  established,  the  SAF  vehicles  acquired  the  SIM¬ 
NET  vehicles  and  immediately  fired.  The  capability  of  more  SAF  entities  is  needed.  (Right  now, 
moving  to  ModSAF,  goes  toward  less  SAF  entities.)  The  current  naming  conventions  for  CMTC-IS 
and  BBS  are  different.  This  caused  problems  with  BOD  AS.  The  memory  on  the  AIU  Central  Pro¬ 
cessing  Unit  card  was  near  capacity  during  STOW-E. 

As  the  capability  of  the  system  continues  to  be  pressed  and  expanded,  there  may  need  to  be  a  re- 
evaluation  to  determine  if  the  current  design  can  reach  the  next  plateau.  While  the  capabilities  were 
rapidly  increased  from  FireStarter  to  STOW-E,  the  system  may  be  reaching  certain  limitations.  Dur¬ 
ing  STOW-E,  the  SAF  engine  was  the  limiting  factor  in  entity  count  capacity.  Entity  counts  fluctu¬ 
ated  from  1163  to  1637  entities,  depending  on  the  training  mission. 

If  there  are  no  aggregate-level  constructive  wargaming  systems  participating  at  STOW97,  then  this 
aggregation/deaggregation  technology  would  not  be  necessary.  If  there  are,  then  the  adequacy  of  this 
technology  would  have  to  be  re-evaluated  due  to  the  high  entity  counts  required  for  STOW97. 

Defense  Simulation  Internet 

The  Defense  Simulation  Internet  (DSI)  is  an  Internet  Protocol  based  network  that  provides  real¬ 
time  simulation  and  video  teleconferencing  to  approximately  100  subscribers  worldwide.  The  DSI 
utilizes  the  Stream  Protocol  to  accommodate  real-time  applications  and  to  support  bandwidth  reser¬ 
vation  and  multicast  capability.  The  DSI  was  necessary  in  supporting  the  communications  require¬ 
ments  for  STOW-E,  which  incorporated  13  DSI  sites  in  the  Continental  United  States  (CONUS), 
Germany,  and  England.  The  classification  of  the  exercise  was  a  combination  of  Secret  No-Foreign 
and  US  1. 


To  support  a  seamless  battle  simulation  for  STOW-E,  DSI  required  a  large  bandwidth  and  robust 
topology.  Various  network  components  were  upgraded  to  increase  available  bandwidth.  In  addition, 
augmenting  systems,  such  as  the  application  gateway,  were  developed  to  optimize  bandwidth  utiliza¬ 
tion. 

For  the  execution  of  STOW-E  over  the  period  of  4  to  7  November  ’94,  during  operations  that  were 
approximately  16  hours  per  day,  reliability  of  the  DSI  was  99%  due  to  network  changes  (improved 
switches  and  redundancy  in  circuit  routing  to  the  sites).  Reliability  was  measured  in  terms  of  hours 
scheduled  versus  hours  usable  by  simulations  to  conduct  testing.  Two  notes  need  to  supplement  this 
apparent  superb  network  performance.  First,  the  network  was  manned  24  hours  a  day  at  every  site 
by  both  the  DSI  “manufacturer”  and  by  the  DSI  “operations  and  maintenance”  contractor.  Secondly, 
the  network  was  brought  down  every  night  for  maintenance  and  re-boot  and  systematically  brought 
back  up.  This  process  took  2  hours  nightly.  While  the  success  of  the  DSI  was  overwhelmingly  posi¬ 
tive  and  a  key  factor  in  the  overall  success  of  STOW-E,  it  was  not  a  hands-off  operation.  Extraordi¬ 
nary  effort  and  hands-on  care  was  devoted  to  the  network  throughout  the  STOW-E  period. 

Over  99%  of  the  traffic  on  DSI  during  STOW-E  was  DIS  Protocol  Data  Units  (PDUs).  The  aver¬ 
age  total  scenario  load  between  4  to  7  November  STOW-E  operations  was  approximately  900  to 
1300  entities  depending  on  the  operation  for  that  day.  The  peak  each  day  during  STOW-E  was  nor¬ 
mally  around  1800  fully  interactive  entities.  Scenario  load  during  testing  prior  to  STOW-E  did  reach 
3500  entities  on  one  occasion.  The  DSI  was  reliable  during  all  of  these  circumstances. 

The  DSI,  in  its  current  configuration,  would  not  be  adequate  for  STOW97  since  the  load  required 
for  STOW97  would  exceed  the  current  available  DSI  bandwidth. 

Scaleability 

The  goal  of  the  Scaleability  program  is  to  support  the  evolution  of  DIS  technology  by  pushing 
back  the  limitations  on  the  number  of  entities  that  can  participate  in  an  exercise.  This  is  a  necessary 
technology  since  the  load  on  the  simulation  network  grows  in  proportion  to  the  entity  count.  The 
load,  at  some  point,  will  exceed  the  available  bandwidth.  To  push  back  this  boundary,  techniques 
were  developed  to  increase  the  density  of  information  that  can  be  transmitted  across  a  given  band¬ 
width. 

For  STOW-E,  approximately  1 800  entities  were  generated  at  sites  around  the  world.  Because  of 
the  geometry  of  the  sites  on  the  network,  high-traffic  segments  of  the  DSI  needed  to  support  a  traffic 
load  of  4.9  megabits  per  second  (Mbps).  The  DSI  was  limited  to  a  throughput  of  1.1  Mbps,  how¬ 
ever,  so  the  offered  load  to  the  network  had  to  be  reduced  by  approximately  80%. 

To  accomplish  the  required  reduction  in  bandwidth  demand,  a  means  was  developed  to  transpar¬ 
ently  determine  whether  generated  data  is  of  value  to  other  sites  in  the  exercise.  If  the  data  is 
required  by  another  site,  it  is  passed  on  to  the  Wide  Area  Network  (WAN);  if  not,  the  WAN  will 
never  see  this  additional  and  unnecessary  load.  This  decision-making  function  was  housed  in  a  com¬ 
puter  on  each  Local  Area  Network  (LAN)  referred  to  as  an  Application  Gateway  (AG).  The  AG  fur¬ 
ther  reduced  the  offered  load  to  the  WAN  by  reformatting  the  data  to  achieve  more  efficient  trans¬ 
missions. 

AG  performance  was  successful  during  STOW-E.  AG  availability  was  99.6%,  and  the  offered 
load  to  the  network,  as  measured  in  pps,  was  reduced  by  a  15:1  ratio. 

While  the  AG  provided  the  means  to  scale  the  Long  Haul  Network  bandwidth  to  operate  within  its 
capacity,  it  did  not  solve  management  of  the  LANs.  Significant  attention  must  be  given  to  LAN  and 
legacy  system  capacities  for  future  STOW  demonstrations/exercises. 
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Scaleability  technology  will  be  necessary  for  STOW97  to  some  degree,  depending  on  the  DSI  net¬ 
work  configuration  and  the  required  network  load  versus  available  bandwidth. 

Live/Range  Instrumentation 

This  technology  was  necessary  for  STOW-E  to  integrate  live  forces  from  instrumented  ranges  via 
DIS.  Live  systems  encounter  different  challenges  than  virtual  and  constructive  systems.  Some  of 
the  challenges  particular  to  live  systems  include  occasional  position  inaccuracy  and  loss  of  connec¬ 
tivity,  limited  bandwidth  between  the  range  and  central  instrumentation  system,  data  latency,  exercise 
control  limitations,  differences  in  exercise  topology  between  live,  constructive,  and  virtual  systems, 
environmental  effects,  and  data  completeness.  In  order  to  provide  the  live  element  of  STOW-E,  the 
CMTC-IS,  the  Tactical  Aircrew  Combat  Training  System  (TACTS),  and  USS  Hue  City  were  inte¬ 
grated  to  the  DIS  network. 

These  technologies  will  be  necessary  for  STOW97  if  live  forces  are  to  be  integrated  with  virtual 
and  constructive  forces.  The  adequacy  of  these  technologies  for  STOW97  will  depend  on  which 
simulation  systems  are  used. 

Combat  Maneuver  Training  Center  (CMTC) 

The  CMTC-IS,  located  in  Hohenfels,  Germany,  was  designed  and  developed  to  support,  through 
analysis  and  feedback,  U.S.  Army,  Europe,  combined  arms  training.  The  instrumented  CMTC  moni¬ 
tors  and  controls  maneuver  training,  produces  after-action  reviews  (AARs),  standardizes  evaluation 
of  training  performance,  and  provides  detailed  training  feedback. 

In  order  for  CMTC-IS  to  participate  in  STOW-E,  an  interface  was  designed  and  developed  to  pro¬ 
vide  a  gateway  to  the  DIS  network  and  thus  a  link  to  other  simulations.  The  CMTC-IS  Brigade 
Operations  Display  and  AAR  System  (BOD AS)  provided  the  CMTC-IS  to  DIS  interface,  the  DIS  to 
brigade  operations  interface,  the  brigade-level  display  capability,  and  the  brigade-level  AAR. 

During  STOW-E,  DIS  PDUs  representing  live  units  in  the  Hohenfels  Training  Area,  were  success¬ 
fully  transmitted  to  the  DIS  network  for  interaction  and  display  with  other  systems  in  Germany.  This 
technology,  along  with  BODAS  and  the  integration  of  other  DIS  systems,  allowed  the  brigade  com¬ 
mander  at  CMTC-IS  to  experience  a  seamless  brigade-level  battle.  Some  problems  were  detected  in 
the  CMTC-IS  to  DIS  interface,  DIS  to  BODAS  interface,  and  brigade  exercise  control,  monitoring, 
and  AAR  areas. 

Tactical  Aircrew  Combat  Training  System  (TACTS) 

The  Tactical  Aircrew  Combat  Training  System  (TACTS)  ranges  are  advanced  training  systems 
designed  to  provide  an  effective  means  to  improve  air  crew  proficiency  in  Air- Air,  Air-Surface  Com¬ 
bat,  and  Electronic  Warfare  mission  areas. 

The  primary  goal  in  STOW-E  was  to  provide  an  interface  unit  to  allow  aircraft  positional  data  and 
weapon  release  signals  provided  by  the  TACTS  range  to  be  transformed  to  the  DIS  protocol  to  pro¬ 
vide  interaction  with  other  virtual  simulation  systems.  Connectivity  of  live  aircraft  with  the  DSI  was 
accomplished  via  the  Tactical  Aircrew  Combat  Training  System/ Air  Combat  Maneuvering  Instru¬ 
mentation  (TACTS/ACMI)  air/ground  radio  frequency  data  link.  The  TACTS/ACMI  integration 
effort  required  the  development  of  the  Advanced  Interface  Units-ground  (AIUgs)  to  provide  the 
interfacing  function  between  the  DSI  and  the  TACTS  range.  The  AIUgs  is  the  gateway  between  the 
TACTS/ACMI  system  and  the  ground-based  simulation  network. 
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Accomplishments  include  the  AlUgs’  ability  to  produce  a  detonation  PDU  when  the  accumulated 
“probability  of  kill”  reached  a  specified  level.  A  live  F/A-18  (Cherry  Point)  was  able  to  be  con¬ 
trolled  by  an  E-2C  controller  (Patuxent  River),  via  the  V4  communications  network.  The  controller 
was  able  to  see  the  F/A-18  on  his  tactical  displays  and  vector  the  pilot  in  for  a  laser-guided  bomb 
drop  against  a  hostile  target. 

USS  Hue  City 

The  stated  primary  objective  of  the  Navy  during  STOW-E  was  to  demonstrate  the  potential  to  train 
personnel  at  all  levels  (from  individual  tactical  console  operators  up  through  the  Battle  Group  Com¬ 
mander)  in  a  DIS  environment.  Additional  goals  included  exposing  the  Fleet  to  DIS  simulation 
potential,  accelerating  development  of  the  Battle  Force  Tactical  Trainer  (BFTT),  and  bench-marking 
Navy  DIS  technology  for  use  in  future  DIS  applications.  To  this  end,  an  active  fleet  AEGIS  cruiser, 
USS  Hue  City  (CG  66),  was  a  participant  in  STOW-E. 

BFTT  is  a  closed  loop,  interactive  simulation,  tactical  combat  training  system.  It  provides  scenario 
generation  and  control,  simulation  of  friendly  and  enemy  forces,  and  stimulation  of  organic  ship¬ 
board  sensors,  data  acquisition,  reconstruction,  and  operator  performance  feedback,  as  well  as  con¬ 
nectivity  with  external  scenario  control  and  communication  with  remote  sites. 

Significant  benefits  from  participation  included  the  revelation  of  some  BFTT  shortcomings,  both 
design  and  performance,  that  will  help  the  BFTT  Program  Office  to  make  corrections  and  enhance 
flexibility.  For  example,  BFTT  performance  began  to  degrade  when  it  handled  more  than  100  enti¬ 
ties.  The  BFTT  Program  Manager  estimates  18  months’  savings  in  development  progress  as  a  result 
of  exposing  the  BFTT  prototype  to  joint  simulation  in  its  early  stages.  The  Navy’s  primary  objective 
of  demonstrating  the  potential  to  train  personnel  at  all  levels,  from  individual  tactical  console  opera¬ 
tors  up  through  the  Battle  Group  Commander,  in  a  DIS  environment,  was  met. 

Terrain  Database 

The  objectives  of  the  ARPA  Synthetics  Environments  Program  include  development  of  advanced 
technology  to  represent  and  generate  digital  terrain  databases  (TDBs)  to  support  increasingly  large 
and  complex  STOW. 

The  STOW-E  synthetic  environments  consist  of  a  family  of  interoperable  TDB  products  that  sup¬ 
port  distributed  ground,  air,  and  naval  simulations  linked  via  DIS  protocols  on  the  DSI.  The  Ground 
Operations  TDB  is  the  highest  resolution  terrain  database  containing  transportation,  vegetation, 
drainage,  soils,  building,  and  other  key  complex  features  of  the  terrain  surface.  It  covers  a  geo¬ 
graphic  area  64  km  by  84  km  that  includes  Grafenwoehr  and  Hohenfels,  Germany.  The  Air  Opera¬ 
tions  TDB  covers  a  geographic  area  of  232  km  by  232  km  in  northern  Bavaria  that  includes  the 
Ground  Operations  TDB  area.  The  Naval  Operations  TDB  covers  a  geographical  area  244  km  by 
244  km  centered  in  the  northern  Mediterranean  Sea.  Automated  TDB  compilers  were  used  to  gener¬ 
ate  the  various  formats  required  by  STOW-E  simulation  systems.  Each  of  the  compilation  activities 
resulted  in  a  database  in  one  of  the  following  formats:  SIMNET  or  Flight  visual  simulation;  “Vista- 
works”;  SAF;  Plan  View  Display;  Management  Command  and  Control  console;  or  BBS  raster  files. 

Modular  Semi-Automated  Forces  (ModSAF) 

What  If  Simulation  System  for  Advanced  Research  and  Development  (WISSARD)  employed 
Modular  Semi-Automated  Forces  (ModSAF)  in  support  of  STOW-E.  WISSARD  also  provided 
Intelligent  Forces  (IFOR),  F-14  simulators,  and  an  F-18  simulator  to  the  STOW-E  demonstration. 
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ModSAF  and  IFOR  Force  Mix  entities  included  the  following  types:  F/A-18,  F-14,  MiG-29,  KS-3 
(vehicle  approximated  by  an  A- 10),  and  airborne  early  warning  and  control  system  (AWACS). 

The  following  are  accomplishments  of  WISS ARD  manned  simulator  operation  during  STOW-E: 
First  formation  flight  with  actual  aircraft,  manned  simulators,  and  computer-generated  forces;  Com¬ 
munication  link  with  “Hawkeye”  Cherry  Point  TACTS  Range  Control  and  with  live  aircraft;  Forma¬ 
tion  flight/coordinated  strike  with  F-16  trainer  (Falcon  Star)  in  Grafenwoehr,  Germany,  with  air  con¬ 
trol  provided  by  the  Tactical  Air  Command  Control  Systems  Facility  (TACCSF)  AWACS;  Formation 
flight/coordinated  strike  (300-nm  route)  with  the  Patuxent  River  F-18  manned  simulator,  the  WIS- 
SARD  F-18  Basic  Air  Tactics  Trainer  (BATT),  the  TACCSF  computer-generated  F-15s,  and  all 
under  TACCSF  AWACS  control;  Formation  flight  on  Armstrong  Labs’  F-16  simulators  at  the  terrain 
database;  and  the  2E6  was  able  to  fly  with  and/or  against  the  F-16  Falcon  Star  from  Germany,  the 
F-16s  out  of  Armstrong  Labs,  the  F-18  Manned  Flight  Simulator  from  Patuxent  River,  and  the  F-15 
from  Kirtland  AFB. 

Given  the  stage  of  the  development  of  the  air  model  for  ModSAF  and  the  relative  lack  of  attention 
it  has  received  over  years  of  ground  maneuver  SIMNET  SAFOR  and  ground  maneuver  ModSAF 
development,  ModSAF  Air  effectively  provides  the  combat  domain  with  a  large  number  of  air  enti¬ 
ties  possessing  basic  offensive  and  defensive  capabilities.  It  proved  to  be  good  for  basic  targeting 
and  to  elicit  initial  behaviors  from  flight  crews. 

Automated  Intelligent  FORces  (IFOR) 

IFOR  stands  for  automated  Intelligent  FORces.  Ideally,  IFORs  allow  replacement  of  human  con¬ 
trol  of  selected  units  on  the  simulated  battlefield  by  automated  control  without  noticeably  degrading 
the  appropriateness  of  the  resulting  behavior.  When  there  are  not  enough  humans  (and  associated 
simulators)  available  to  fully  populate  the  battlefield,  populating  it  with  even  “dumb”  IFORs  yields 
more  realism  than  would  leaving  it  inappropriately  unpopulated.  This  may  be  a  viable  technology 
for  use  at  STOW97. 

IFOR  goals  for  participation  in  STOW-E  were  to  participate  in  a  large-scale  operational  exercise, 
learn  what  is  required  for  theater-level  exercises,  provide  viable  IFOR  opponents  for  human  and 
ModSAF  forces,  and  to  learn  about  what  is  required  for  more  advanced  IFOR  opponents  in  air-to-air 
and  air-to-ground  combat. 

Air-to-air  missions  were  successfully  performed  against  ModSAF  and  humans  in  the  BATTs  and 
the  2E6.  The  attempt  was  made  to  engage  planes  from  other  sites,  but  they  never  reacted  to  the 
IFOR  planes,  and  would  typically  fall  off  the  net  before  the  IFOR  planes  could  get  off  missile  shots. 
The  IFOR  planes  also  participated  in  air-to-ground  (bombing  bridges,  etc.)  and  air-to-surface  (firing 
missiles  at  ships)  attacks  in  which  there  were  successful  engagements  with  ground  and  surface  tar¬ 
gets  from  other  sites. 

There  were  a  limited  number  of  software  failures  with  the  most  significant  being  the  inability  to 
fly  over  the  terrain  database  where  the  ground  battle  was  raging  when  it  was  populated  with 
hundreds  of  tanks.  There  was  no  problem  flying  over  the  terrain  database  when  it  was  not  populated 
with  tanks — this  was  tested  when  Europe  was  off-line. 

Overall,  viable  IFOR  opponents  were  provided;  however,  it  was  difficult  to  evaluate  the  “skill”  of 
IFOR  planes  because  of  problems  with  the  underlying  simulation  models.  A  disappointment  was  the 
number  of  IFOR  vehicles  that  could  effectively  be  run  on  a  single  machine  during  these  engagements 
(maximum  of  four).  This  exercise  demonstrated  that  artificial  intelligence  (AI)  technology  can  be 
successfully  used  in  an  operational  exercise. 
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TECHNIQUES 


Experimental  PDUs 

In  the  development  of  STOW-E,  a  number  of  experimental  PDUs  were  developed  at  the  Naval 
Command,  Control  and  Ocean  Surveillance  Center  (NCCOSC)  RDT&E  Division  (NRaD)  and  at  the 
Naval  Underwater  Warfare  Center  to  supplement  those  PDUs  defined  in  the  DIS  protocol  standard. 
The  Application  Gateway-to-Gateway  Protocol  was  used  to  reduce  the  number  of  standard  PDUs 
sent  on  the  DSI.  This  reduction  allowed  for  data  to  be  exchanged  between  sites  within  an  effective 
bandwidth  of  1.05  Mbps  (a  limitation  imposed  on  STOW-E  by  the  DSI  T1  telephone  line). 

Security 

STOW-E  was  executed  as  a  multi-security-level  exercise.  Unclassified,  US1,  and  Secret  No- 
Foreign  simulation  sites  were  linked  together  over  the  DSI  during  STOW-E  via  one-way  data  links. 
Motorola’s  Improved  Performance  Network  Encryption  System  (INES)  was  used  to  provide  National 
Security  Agency  approved  encryption  at  the  secret  level  between  classified  sites.  Modifications  to 
existing  network  architecture  allowed  classified  STOW-E  sites  to  view  and  interact  with  entities  gen¬ 
erated  at  unclassified  sites,  in  a  limited  way.  Unclassified  sites  were  unable  to  see  or  interact  with 
any  entities  generated  by  classified  sites. 

The  security  guard  worked  as  planned,  designed,  approved,  and  engineered.  Early  recognition  of 
security  issues  and  appropriate  early  and  thorough  action  to  mitigate  security  risk  were  instrumental 
in  making  security  a  non-issue  for  STOW-E.  However,  for  future  STOW  demonstrations/exercises,  ' 
the  INES  and  the  guard  should  be  reviewed  to  determine  if  they  are  adequate  for  large  and  more 
complex  exercises.  They  probably  are  not  sufficient  for  STOW97. 

Tactical  Communications 

The  purpose  of  the  Support  and  Tactical  Communications  was  to  provide  the  nondata  communica¬ 
tions  support  required  for  STOW-E.  The  nets  were  organized  to  simulate  Tactical  Radio  Nets  that 
would  be  found  in  use  by  the  Tactical  units  simulated.  This  operation  was  accommodated  by  provid¬ 
ing  audio  teleconference  calls  to  replicate  the  nets,  using  Defense  Switched  Network  (DSN)  and  Fed¬ 
eral  Telephone  System  (FTS)  bridges.  DSN  was  used  for  all  conference  calls  involving  overseas 
subscribers.  FTS  was  used  to  support  all  CONUS-only  conference  calls.  MCI  Forum  was  available 
for  backup.  DSN  was  used  because  of  cost  considerations,  and  because  FTS  does  not  cover  CONUS 
calls. 

None  of  the  circuits  were  covered;  hence,  the  voice  communications  were  “in  the  clear."  In  some 
instances,  had  secure  voice  been  provided,  more  realism  could  have  been  achieved.  However,  for 
STOW-E,  the  cost  vs.  value  was  not  beneficial.  Use  of  the  DSN  caused  pre-emption  in  some  cases, 
which  interrupted  operations.  Yet  overall,  pre-emption  on  the  DSN  was  minimal  ( 1 0  to  1 5%). 

Technical  Control 

This  area  of  responsibility  entailed  functions  relating  to  the  operation  of  STOW-E  hardware  and 
software  located  in  the  STOW-E  Exercise  and  Analysis  Facility  (SEAF)  at  Grafenwoehr,  Germany, 
and  at  participating  sites,  with  the  exception  of  communications  and  data  analysis  functions. 

SEAF  Technical  Control  was  defined  by  the  stations  manned  during  STOW-E.  These  stations 
were  Technical  Control  Manager,  Technical  Control  Supervisor,  Network  Supervisor,  DSI  Opera¬ 
tions  Engineers,  Application  Gateway  Engineer,  Net  Visualizer  Analyst,  Stealth  Operator,  Army  Site 
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Status  Projection  Operator,  Navy  Site  Status  Projection  Operator,  Air  Force  Site  Status  Projection 
Operator,  Technologies  Status  Projection  Operator,  Stealth  3-D  Naval  Shipping  Operator,  Stealth  3-D 
Navy/ Air  Force  Operator,  and  DSI  Network  Status  Projection  Operator.  For  sites  other  than  the 
SEAF,  stations  staffed  will  be  as  required  by  the  size,  equipment,  and  scenario  involvement  at  each 
particular  site. 

For  STOW97,  this  technique  is  necessary  but  will  need  to  be  customized  by  adding  or  subtracting 
stations  reflecting  the  complexity  of  specific  program/project  objectives  and  goals.  Factors  of 
resource  availability,  number  and  technical  maturity  of  sites,  expected  external  interest  levels,  and 
joint  aspects  will  determine  the  number  of  technical  control  stations. 

Data  Collection  and  Analysis 

STOW-E  analysis  was  divided  into  three  areas:  technical  analysis,  real-time  and  after-action  sce¬ 
nario  review,  and  operational  analysis.  Technical  analysis  addresses  the  performance  of  the  DSI  net¬ 
work,  and  the  various  systems  and  simulations  operating  on  the  network.  Real-time  and  after-action 
scenario  review  assess  the  execution  of  the  military  scenario.  Operational  analysis  addresses  the 
effectiveness  of  the  military  training  of  the  demonstration. 

Data  analysis  efforts  are  focused  on  technical  issues.  Technical  analysis  includes  the  assessment 
of  the  performance  of  the  Application  Gateway  (AG),  the  characterization  of  DIS  traffic,  and  the 
estimation  of  delays  across  the  network.  The  individual  site  DIS  data  log  files  are  available  to  sup¬ 
port  military  after-action  reviews.  Merging  individual  site  files  to  construct  complete,  ground-truth 
log  files  for  selected  portions  of  STOW-E  is  on-going.  This  composite  file  will  also  support  military 
after-action  review.  Operational  analysis  is  being  conducted  by  the  7th  Army  in  Grafenwoehr,  Ger¬ 
many,  as  well  as  Navy  and  Air  Force  designated  analytical  efforts,  such  as  the  Center  for  Naval 
Analysis. 

The  NRaD  DIS  Data  Logger  (DLogger)  was  used  to  record  the  DIS  traffic  during  STOW-E.  The 
DLogger  records  DIS  PDUs  along  with  a  time-stamp  corresponding  to  when  the  PDU  was  detected 
on  the  LAN  by  the  DLogger.  Data  was  recorded  on  the  local  simulation  LAN  at  each  STOW-E  site. 
In  addition  to  recording  simulation  LAN  traffic,  the  two  black  sites,  Ft.  Rucker  and  SIMNET,  logged 
data  on  the  WAN  side  of  the  AG.  The  SEAF,  in  Grafenwoehr,  Germany,  also  logged  selected  LAN 
and  WAN  network  traffic  using  SGI’s  Network  Visualizer  software. 

Characterization  of  DIS  traffic  loads  is  critical  for  network  bandwidth  allocation.  DIS  simulation 
load  is  a  function  of  the  simulation  system,  the  number  and  types  of  entities  being  generated,  the 
entities’  levels  of  activity,  and  the  dead-reckoning  algorithm  being  used.  DSI  network  delay  will  be 
estimated  for  selected  segments/periods  of  the  STOW-E  exercise.  STOW-E  results  for  technical  per¬ 
formance  in  this  area  are  proving  to  be  very  time-consuming;  therefore,  a  separate  report  will  be  pub¬ 
lished. 

Test  and  Integration 

Test  and  Integration  covers  the  STOW-E  test  efforts  from  April  through  November  1994  including 
STOW-E  planning  meetings,  Subsystem  Integration  Tests,  Review  and  Planning  meetings,  Func¬ 
tional  Validation  Tests,  System  Integration  Tests,  and  the  STOW-E  technology  demonstration. 

A  preliminary  test  requirements  list  was  developed  using  the  STOW-E  System  Requirements  Doc¬ 
ument  as  a  starting  point.  Exit  criteria  and  measures  of  success  were  developed  specifically  for  each 
requirement.  Schedules  were  developed  and  maintained  to  show  upcoming  events,  major  concurrent 
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military  exercises,  scheduled  site  participation,  and  site  DIS  node  installation  status.  Master  sched¬ 
ules  were  generated  and  displayed  at  NRaD  and  were  used  as  the  basis  for  test  planning  and  coor¬ 
dination  of  associated  activities.  A  trouble  report  process  was  incorporated  into  the  test  effort. 
Activity  Logs  were  kept  with  as  much  detail  as  practical  for  the  log  keeper.  At  the  end  of  each  test 
period,  a  test  report  was  written  and  distributed. 

When  STOW-E  was  completed,  over  50  trouble  reports  remained.  These  trouble  reports  must  be 
addressed  before  there  are  future  demonstrations/exercises. 
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1.0  INTRODUCTION 


The  Synthetic  Theater  of  War  -  Europe  (STOW-E)  was  a  joint  research  effort  run  concurrently 
with  ATLANTIC  RESOLVE  94,  a  joint  service  training  exercise.  STOW-E  was  conducted  4  to  7 
November  1994,  with  an  After-Action  Review  on  8  November  1994.  Many  technologies  and  tech¬ 
niques  were  researched  and  integrated  to  enable  live,  virtual,  and  constructive  simulation  systems  to 
be  integrated  into  a  seamless  warfighting  environment  that  will  aid  future  warfighters  in  training  that 
will  hone  the  skills  required  in  a  tactical  environment. 

1.1  PROJECT  GOALS 

1.1.1  ARPA  Goals 

The  principal  objective  from  the  perspective  of  the  Advanced  Research  Projects  Agency  (ARPA) 
is  to  develop  a  Synthetic  Theater  of  War  (STOW)  to  demonstrate  the  feasibility  and  utility  of 
Advanced  Distributed  Simulation  (ADS)  as  a  realistic,  cost-effective  tool  for  joint  service  training 
and  rehearsal,  and  to  support  service  acquisition  programs.  An  additional  objective  is  to  transition 
ADS  technologies  for  use  by  the  joint  service  communities.  STOW-E  served  as  a  first  “stepping 
stone”  on  the  path  to  STOW. 

1.1.2  Army  Goals 

The  specific  goal  of  STOW-E  ,  from  the  U.S.  Army  perspective,  was  to  provide  an  interim  capa¬ 
bility  to  support  training  by  using  existing  virtual  world  simulators,  constructive  model  simulations, 
and  instrumented  vehicles.  The  use  of  Distributed  Interactive  Simulation  (DIS)  protocols,  interface 
capabilities,  and  the  Defense  Simulation  Internet  (DSI)  was  to  provide  operational  commanders  an 
opportunity  to  train  with  fewer  of  the  artificialities  normally  associated  with  previous  efforts  to 
manually  link  such  systems. 

1 .1 .3  Navy  Goals 

The  U.S.  Navy  project  goal  was  to  demonstrate  a  potential  for  fleet  training,  in  a  DIS  environment, 
of  all  echelons  from  the  battle  group  commander  to  tactical  console  operators.  Navy  participation 
was  guided  by  three  overriding  considerations:  (1)  involvement  to  be  doctrinally  correct  and  opera¬ 
tionally  relevant,  in  line  with  “From  The  Sea”  and  forthcoming  Naval  Doctrine  Pub  - 1 ;  (2)  the 
Navy  to  share  and  contribute  in  scenario  development;  and  (3)  training  to  be  demonstrated  with  fleet 
operators  participating  in  all  man-in-the-loop  simulations. 

1.1.4  Air  Force  Goals 

The  U.S.  Air  Force  goal  was  to  gain  experience  with  the  training  capabilities  that  STOW-E 
technology  can  support,  and  to  provide  input  into  future  development  of  technology.  Air  Force  par¬ 
ticipation  in  STOW-E  was  limited  to  sites  where  available  technology  could  support  air  operations 
that  were  tactically  relevant,  doctrinally  sound,  and  that  could  make  a  visible  contribution  to  opera¬ 
tions  being  conducted. 

1.1.5  DMSO  Goals 

The  Defense  Modeling  and  Simulation  Office  (DMSO)  goal  was  to  expand  DoD’s  simulation 
infrastructure,  broaden  the  use  of  modeling  and  simulation  to  support  DoD  functional  requirements, 
and  work  toward  interoperability  of  modeling  and  simulation  tools  and  applications. 
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1.2  CONCEPT 

Under  the  STOW  concept,  DIS-compliant  simulation  systems  may  enter  into  the  network  and  par¬ 
ticipate  in  STOW  exercises.  This  might  include  DIS-compliant  simulators  such  as  aircraft,  ships, 
missiles,  tanks,  and  other  weapons  systems  of  the  Army,  Navy,  and  Air  Force  working  together  to 
make  a  more  realistic  exercise. 

During  STOW-E,  live  instrumented  vehicles  at  the  Combat  Maneuver  Training  Center  (CMTC), 
Hohenfels,  Germany,  were  linked  with  the  Brigade/Battalion  Battle  Simulation  (BBS)  System  and 
the  Simulation  Network  (SIMNET)  simulators  at  Grafenwoehr,  Germany.  This  permitted  a  heavy 
ground  combat  brigade,  consisting  of  three  battalion  task  forces,  command  and  control  elements, 
combat  support  (CS)  and  combat  service  support  (CSS)  elements  of  the  brigade,  to  train  together. 
Each  battalion  task  force  made  use  of  one  of  the  three  simulation  systems  to  conduct  its  assigned  tac¬ 
tical  missions  in  a  brigade-sized  battle  and  to  deploy  and  fight  at  the  entity  level.  Through  the  use  of 
a  DIS  Interface  Unit,  they  were  able  to  affect  cross-boundary  operations  using  direct  and  indirect 
fire,  as  well  as  air  assets.  The  brigade  commander  had  the  ability  to  influence  the  outcome  of  a  close 
fight  by  planning  and  executing  operations  against  enemy  formations  in  the  areas  “beyond  visual 
range.” 

Naval  forces  included  battle  group  power  projection  operations  in  support  of  Army  brigade-size 
forces,  and  consisted  of  air,  surface,  and  subsurface  units.  Included  in  the  seven  Navy  sites  that  par¬ 
ticipated  in  battle  group  interactions  across  the  Defense  Simulation  Internet  were  a  live  AEGIS 
cruiser,  instrumented  live  aircraft,  and  both  man-in-the-loop  and  computer-generated  simulations. 

Air  Force  participation  consisted  of  manned  simulators  at  five  sites  flying  composite  missions  in 
support  of  the  joint  operations. 

1.3  SCOPE 

STOW-E  was  co-sponsored  by  ARPA,  DMSO,  and  the  U.S.  Army  Europe,  7th  Army  Training 
Command,  Grafenwoehr,  Germany,  with  supporting  U.S.  Navy  and  Air  Force  participation.  The 
focus  of  STOW-E  was  the  integration  of: 

a.  Live  instrumentation  with  the  Combat  Maneuvering  Training  Center  -  Instrumentation  System 
(CMTC-IS),  Hohenfels,  Germany. 

b.  Constructive  simulation  with  BBS  using  the  BBS-AIU  with  Semi-Automated  Forces  4.3.3 
(SAF  4.3.3)  simulator,  Hohenfels,  Germany. 

c.  Virtual  simulation  with  the  SIMNET  and  with  the  Semi-Automated  Forces  (SAF  3.10)  simula¬ 
tor,  Grafenwoehr,  Germany. 

d.  Virtual  simulation  with  the  Air  Network  (AIRNET)  simulator  and  with  the  Semi-Automated 
Forces  (SAF  4.3.3)  simulator,  Fort  Rucker,  AL. 

e.  Technical  and  exercise  control  at  the  STOW-E  Evaluation  and  Analysis  Facility  (SEAF),  Gra¬ 
fenwoehr,  Germany. 

f.  Live  instrumentation  with  the  Tactical  Air  Crew  Training  System  (TACTS),  Marine  Corps  Air 
Station  (MCAS)  Cherry  Point,  NC. 

g.  Virtual  simulation  with  the  SSN  688  Submarine  Trainers  at  the  Naval  Undersea  Warfare  Cen¬ 
ter  (NUWC),  Newport,  RI. 

h.  Virtual  simulation  with  the  What  If  Simulation  System  for  Advanced  Research  and  Develop¬ 
ment  (WISSARD),  and  with  the  Modular  Semi-Automated  Forces  (ModSAF)  simulator,  NAS 
Oceana,  VA. 
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i.  Virtual  simulation  with  the  Battle  Force  Tactical  Trainer  (BFTT)  at  the  Fleet  Combat  Training 
Center  Atlantic  (FCTCLANT),  Dam  Neck,  VA. 

j.  Live  instrumentation  with  USS  Hue  City  (CG  66),  an  AEGIS  cruiser,  berthed  at  Naval  Station, 
Mayport,  FL. 

k.  Virtual  simulation  with  the  E-2C  and  F/A-18  simulators  at  Naval  Air  Warfare  Center  - 
Aircraft  Division  (NAWC-AD),  Naval  Air  Station  (NAS)  Patuxent  River,  MD. 

l.  Virtual  simulation  with  BFTT  TAC-III  consoles  simulating  an  AEGIS  combat  suite  at  the 
AEGIS  Computer  Center,  Naval  Surface  Warfare  Center  -  Dahlgren  Division  (NSWC-DD), 
Dahlgren,  VA. 

m.  Virtual  simulation  with  the  FALCON  STAR  manned  simulator  at  Spangdahlem  Air  Force  Base 
(AFB),  Germany. 

n.  Virtual  simulation  with  cockpit  simulators  at  the  USAF  Armstrong  Laboratories,  Mesa,  AZ. 

o.  Virtual  simulation  with  USAF  cockpit  simulators  at  Royal  Air  Force  (RAF)  Lakenheath,  Eng¬ 
land. 

p.  Virtual  simulation  with  cockpit  simulators  at  the  USAF  Theater  Battle  Arena,  the  Pentagon. 

q.  Virtual  simulation  with  cockpit  simulators  at  Theater  Air  Command  and  Control  Simulation 
Facility  (TACCSF),  Kirtland  AFB,  NM;  and 

r.  Monitoring  with  the  Institute  for  Defense  Analysis  (IDA)  Viewport,  Arlington,  VA. 

Figure  1-1  illustrates  the  scope  of  STOW-E. 

1.4  DOCUMENT  OVERVIEW 

This  document  details  the  technologies  and  techniques  developed  for  STOW-E.  Included  is  a 
detailed  description  of  each  technology  or  technique  along  with  achievements  and  lessons  learned 
from  the  STOW-E  demonstration.  This  document  is  organized  into  five  sections.  Sections  1.0  and 
2.0  are  the  introduction  and  applicable  documents  sections,  respectively.  Section  3.0  contains 
aggregation/  deaggregation,  scaleability,  live/range  instumentation,  terrain  database,  modular  semi- 
automated  forces,  defense  simulation  internet,  and  intelligent  forces  technologies.  Section  4.0  con¬ 
tains  experimental  protocol  data  units,  security,  tactical  communications,  technical  control,  data 
collection  and  analysis,  and  test  and  integration  techniques.  Section  5.0  is  a  list  of  acronyms  and 
abbreviations. 
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Figure  1  -1 .  The  scope  of  STOW-E. 


2.0  DOCUMENTS 


Proposed  IEEE  Standard  Draft:  Standard  for  Information  Technology  -  Protocols  for  Distributed 
Interactive  Simulation  Applications,  Version  2.0,  Third  Draft,  Institute  for  Simulation  and  Training, 
May  28,  1993. 
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3.0  TECHNOLOGIES 


3.1  AGGREGATION/DEAGGREGATION 

3.1.1  Background 

Aggregation/Deaggregation  was  born  from  the  attempt  to  link  a  constructive  model,  such  as  the 
BBS,  which  uses  icons  representing  multiple  individual  entities,  with  a  virtual  model,  such  as  SIM- 
NET  or  DIS  technologies,  where  all  units  are  represented  as  individual  entities.  The  problem  facing 
the  team  was  the  development  of  methods  for  resolving  the  differences  between  these  simulation 
environments,  and  presenting  to  the  users  of  each  simulation  an  interoperable  system  on  a  common 
battlefield. 

3.1.2  Issues 

The  essential  dissimilarity  between  these  simulation  environments  needed  to  be  resolved  in  several 
technical  areas:  aggregation/deaggregation  (BBS  units  vs.  DIS  individuals),  timing  (BBS  15-second 
updates  vs.  DIS  continuous  updates),  combat  resolution  (BBS  “roll  of  the  dice”  Battle  Damage 
Assessment  (BDA)  vs.  DIS  individual  deterministic  BDA),  terrain  database  correlation  (BBS  100-m 
grid  resolution  vs.  DIS  30-  to  120-m  variable  resolution),  training  audience  and  objectives  (BBS  Bri¬ 
gade/Battalion  Commander  and  staff,  and  Combat  Support/Combat  Service  Support  vs.  SIMNET 
Company/Platoon  Commander  and  Combat/Maneuver),  network  bandwidth,  and  command  and  control. 

3.1.3  Approach 

To  bridge  the  gap  between  the  constructive  simulation  and  the  virtual  simulators,  an  aggregation/ 
deaggregation  technology  was  created  by  integrating  the  Advanced  Interface  Unit  (AIU)  and  the 
Semi-Automated  Forces  (SAF)  engine.  The  AIU  provided  the  interfaces  between  the  BBS  simula¬ 
tion  and  the  SIMNET  simulators,  performed  translation  between  DIS  and  SIMNET  protocols,  per¬ 
formed  dead  reckoning  of  DIS  entities,  and  provided  necessary  functionality  that  was  missing  in  the 
SAF.  The  SAF  engine  performed  the  actual  modeling  of  the  deaggregated  BBS  entities  as  individual 
vehicles  and  provided  several  basic  maneuver  and  combat  support  functions. 

To  maintain  this  common,  or  seamless,  simulation,  the  following  basic  ground  rules  were  fol¬ 
lowed: 

a.  Provide  the  same  tactical  picture  in  the  interoperating  simulations  at  all  times. 

b.  Preserve  credibility  of  the  tactical  picture  in  time  and  space  after  repeated  aggregations  and 
deaggregations. 

c.  Resolve  interactions  (movement,  visibility,  engagement)  in  the  higher  fidelity  simulation  for 
that  interaction  and  pass  results  back  to  the  lower  fidelity  system  to  the  extent  possible. 

d.  Construct  a  virtual  sphere  of  influence  to  regulate  computer  system  and  network  capacities. 

3.1 .3.1  Aggregation/Deaggregation.  For  aggregation,  user-defined  mapping  tables  were  estab¬ 
lished  to  map  SIMNET  individual  vehicle  bumper  numbers  into  platoons  that  could  be  subsequently 
handled  in  BBS.  For  example,  four  SIMNET  vehicles  All,  A12,  A13,  and  A14,  would  be  mapped 
to  one  BBS  unit  (icon)  1/A/ ARM-7.  Location  of  the  aggregate  unit  in  BBS  was  calculated  as  the 
“center  of  mass”  location  for  the  SIMNET  vehicles  in  that  unit.  For  deaggregation,  BBS  units  of 
varying  sizes  (between  1  and  20  vehicles)  were  passed  as  a  unit  to  the  AIU,  which  would  then  ask  a 
SAF  engine  to  create  the  correct  number  and  type  of  vehicles  in  a  specified  formation.  Also,  aggre¬ 
gate  Protocol  Data  Units  (PDUs)  were  sent  out  on  all  BBS  units. 


7 


3.1 .3.2  Timing.  To  handle  the  time  discrepancy,  the  information  on  deaggregated  BBS  units, 
including  location,  BDA,  etc.,  that  changed  in  the  15-second  period  was  passed  back  to  BBS  for  the 
next  update. 

3.1 .3.3  Combat  Resolution.  The  principle  discussed  above  of  performing  functions  in  the  higher 
fidelity  model  was  applied  to  combat  resolution.  BDA  is  performed  in  SAF/SIMNET  for  those 
vehicles  that  have  been  deaggregated  because  of  the  higher  fidelity  of  determining  BDA  at  the  indi¬ 
vidual  vehicle  level.  Damage  results  from  the  combat  action  are  passed  back  to  the  BBS  operator  as 
they  occur.  Personnel  status  is  tracked  via  BBS  algorithms,  since  SIMNET  does  not  track  personnel. 

3. 1.3.4  Terrain  Database  Correlation.  Once  again  terrain  discrepancies  and  Line-of-Sight  (LOS) 
calculations  were  performed  in  the  simulation  with  higher  fidelity  terrain  (which  is  the  SAF  terrain). 
Also,  a  BBS  digital  database  was  built  from  the  same  source  as  the  SAF  terrain  database  to  gain  bet¬ 
ter  correlation  between  the  database  features.  SIMNET  maps  were  provided  to  assist  in  the  planning 
of  movements  for  the  BBS  operators. 

3.1 .3.5  Training  Audience  and  Objectives.  The  BBS  training  audience  was  the  battalion  and 
brigade  commanders,  and  their  staffs  in  their  Tactical  Operation  Center  (TOC);  this  audience  nor¬ 
mally  concentrated  on  CS  and  CSS  areas.  In  SIMNET,  the  training  audience  was  the  company  and 
platoon  commanders,  and  their  tank  crews;  they  focused  on  team  training  for  maneuver  and  combat 
areas. 

3.1. 3.6  Network  Bandwidth.  Exceeding  network  and  system  capacity  was  a  continual  concern. 
Methods  were  developed  to  try  to  regulate  the  number  of  entities  in  the  simulation  so  as  not  to 
exceed  SAF  engine  capability  or  load  the  network  unnecessarily.  A  Sphere  of  Influence  (SOI)  model 
was  developed  to  help  regulate  the  number  of  deaggregated  BBS  entities.  Local  Collision  PDUs 
from  SAF  generated  units  were  filtered  out  to  prevent  them  from  going  onto  the  network  and  causing 
additional  traffic.  The  filtering  of  incoming  PDUs  by  the  AIU,  by  site,  helped  keep  the  Local  Area 
Networks  (LANs)  of  SAF  engines  and  Stealth  from  bogging  down  under  high  loads. 

3.1 .3.7  Command  and  Control.  The  BBS  operator  had  certain  control  over  his  deaggregated 
unit.  He  could  change  speed,  fire  posture,  engagement  range,  and  formations.  The  particular  forma¬ 
tions  that  the  BBS  operator  could  give  a  unit,  called  opstates,  were  mapped  to  SAF  command 
instruction  sets  to  aid  in  command  and  control  of  a  unit. 

3.1.4  Benefits 

The  linkage  was  designed  to  exploit  the  strengths  of  both  simulations,  combining  the  command 
and  control  structure,  and  the  combat  support  and  combat  service  support  functions  of  the  BBS 
constructive  simulation,  with  the  combat  functionality  of  the  SIMNET  virtual  simulators.  This 
allowed  for  simultaneous  training  from  the  brigade  commander  and  staff,  to  the  individual  soldier.  It 
is  hoped  that  the  techniques  applied  to  this  problem  can  also  apply  to  the  interoperation  of  other  sim¬ 
ulations. 

3.1.5  Demonstrations  and  Exercises 

Several  exercises  and  demonstrations  have  been  supported  along  the  path  to  integration;  most 
notable  are: 

MAR  ’94  FIRESTARTER  Operational  Exercise  in  Grafenwoehr.  This  was  the  first  brigade- 
level  exercise  including  the  AIU  (three  Central  Processing  Units  (CPUs))  and  three  SAF  engines 
capable  of  300  to  400  entities. 
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MAY  ’94  CINC  USAREUR  Demonstration  in  Grafenwoehr. 

AUG  ’94  1AD  (Air  Defense)  Operational  Exercise  in  Hohenfels  and  Grafenwoehr. 

SEP  ’94  STOW-E  Functional  Validation  #2  Test  in  Hohenfels  and  Grafenwoehr. 

OCT  ’94  SECDEF  Demonstration  in  Hohenfels  and  Grafenwoehr. 

NOV  ’94  STOW-E  Operational  Exercise  in  Hohenfels  and  Grafenwoehr.  This  brigade-level 
exercise  included  the  AIU  (five  CPUs,  shared  memory)  and  nine  SAF  engines  that  when  combined 
were  capable  of  1000  to  1 100  entities. 

3.1.6  BBS  STOW-E  Exercise 

3.1 .6.1  Goal.  The  goal  of  the  Aggregation/Deaggregation  project  for  STOW-E  was  to  implement 
the  BBS/SIMNET  interface  into  an  operational  exercise  and  include  interactivity  with  the  CMTC 
Live  Instrumented  Range,  thus  providing  the  enabling  technologies  for  aggregate-level  constructive 
wargaming  systems  (BBS),  individual  virtual  simulators  (SIMNET),  and  individual  live  combatants 
(CMTC-IS)  to  interact  in  a  joint  training  exercise. 

3.1 .6.2  Challenge.  The  challenge  was  to  provide  an  operationally  useful  interface  allowing  seam¬ 
less  integration  of  each  domain  as  operational  missions  are  performed.  This  would  include  a  CMTC 
Battalion  Task  Force  (BTF)  for  both  Blue  Forces  (BLUFOR)  and  Opposing  Forces  (OPFOR)  in  the 
CMTC  Sector;  a  BBS  BTF  for  both  BLUFOR  and  OPFOR  in  the  BBS  Sector;  and  a  SIMNET  BTF 
with  BBS  CS/CSS  support  forces  for  BLUFOR  and  a  BBS  BTF  for  OPFOR  in  the  SIMNET  Sector. 
The  BBS/SIMNET  interface  was  to  support  the  missions,  as  required,  between  the  sectors. 

3.1 .6.3  Configuration.  Figure  3-1  depicts  the  BBS/SIMNET  STOW-E  architecture.  The  BBS/ 
SIMNET  link  was  established  at  the  BBS  Warlord  site  at  CMTC  Hohenfels,  Germany.  The  system 
consisted  of  nine  SAF  engines  (Silicon  Graphics,  Incorporated  (SGI)  Indy’s)  running  SAF  4.3.3  soft¬ 
ware  and  using  the  STOW-E  terrain  database  (stowe-0105  ctdb)  for  modeling  the  BBS  deaggregated 
units;  one  AIU  (Versa  Modula  Europa  (VME)  card  cage  with  five  CPU  cards.  Shared  Memory  card, 
and  Hard  Disk)  with  thin/thicknet  connections  to  BBS,  SIMNET,  and  DIS  networks  for  providing  the 
interface  between  the  domains  (including  the  DIS/SIMNET  protocol  translation  and  the  aggregate 
PDU  generation);  one  ModSAF  1.2  Plan  View  Display  (PVD)  (SGI  Indigo2  Extreme)  for  displaying 
and  monitoring  the  DIS  traffic;  one  Development  System  (SGI  Indigo2  Extreme)  for  data  logging 
and  monitoring  entity  counts;  one  SAF  4.3.3  PVD  (SGI  Indigo2  Extreme)  for  Stealth  control;  one 
Stealth  View  (GT110)  for  pre-exercise  movement  setup  and  movement  monitoring  during  the  exer¬ 
cise;  and  three  terminals  (VT320s)  for  SIMCON  control. 

The  SAF  Engines,  SAF  4.3.3  PVD,  two  AIU  SIMNET  CPUs,  and  Stealth  View  were  on  a  separate 
thicknet  LAN  using  SIMNET  protocols.  The  VT320s,  one  AIU  BBS  CPU,  and  17  BBS  Worksta¬ 
tions  were  on  a  separate  thinnet  LAN  using  BBS  specific  protocols. 

The  ModSAF  1.2  PVD,  Development  System,  and  two  AIU  DIS  CPUs  were  on  a  separate  thinnet 
LAN  using  DIS  protocols. 
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Figure  3-1.  BBS/SIMNET  STOW-E  architecture. 


The  17  BBS  Workstations  were  divided  up  as  12  BBS  Workstations  to  support  the  BLUFOR 
operation  in  building  1270,  and  5  BBS  Workstations  to  support  the  OPFOR  operation  in  a  temporary 
tent  co-located  with  building  1270.  An  additional  2  BBS  Workstations  were  located  in  the  SIMNET 
building  2000  in  Grafenwoehr,  Germany,  to  support  BLUFOR  operations.  These  workstations  were 
connected  via  modem  to  building  1 270  and  were  used  for  CS/CSS  operations  in  support  of  the  SIM¬ 
NET  task  force  in  the  SIMNET  sector.  The  BBS  STOW-E  terrain  database  was  the  digital  database 
used  during  the  exercise.  SIMNET  maps  were  put  together  to  allow  BBS  operators  to  visually  corre¬ 
late  movements  on  their  BBS  maps  with  the  SIMNET  maps. 

The  DIS  LAN  was  connected  to  a  fiber-optic  network  that  ran  to  a  bridge  in  CMTC  building  100, 
through  Well  Fleet  routers  to  a  similar  setup  at  the  SIMNET  building  2000.  A  subset  of  the  AIU, 
called  the  Advanced  Translator  Unit  (ATU)  was  setup  at  the  SIMNET  site  to  convert  the  incoming 
DIS  and  outgoing  SIMNET  traffic  for  the  60  SIMNET  Tank  simulators  and  the  one  Dismounted 
Infantry  (DI)  simulator  at  the  SIMNET  site.  The  ATU  consists  of  a  VME  card  cage  with  four  CPU 
cards  with  interfaces  to  the  SIMNET  and  DIS  networks. 

Security  measures  were  enforced  for  the  entire  building  1270/tent  complex.  A  fence  was 
constructed  around  the  perimeter  with  rolls  of  concertina  wire  as  well.  A  guard  was  posted  just 
inside  the  gate  at  1270  to  check  badges  and  issue  visitor  passes.  A  guard  was  also  posted  inside  the 
OPFOR  tent  for  similar  duties. 

3.1. 6.4  BBS  STOW-E  Achievements.  BBS/SIMNET  interface  achievements  include  the  interac¬ 
tions  between  the  constructive,  virtual,  and  live  domains  as  described  here: 

a.  BBS  tank  platoons  being  controlled  by  BBS  soldier  operators  in  Hohenfels  engaged  and 
destroyed  SIMNET  tank  simulators  being  driven  by  soldiers  in  Grafenwoehr.  The  BBS  opera¬ 
tor  sees  a  platoon  icon  representing  a  SIMNET  platoon  on  his  workstation. 

b.  BBS  tank  platoons  fired  on  CMTC-IS  real  tanks  being  driven  in  the  “box”  (Hohenfels  combat 
maneuver  training  area).  The  interface  precluded  destmction  of  real  entities  by  virtual  entities. 

c.  BBS  artillery  missions  were  fired,  subsequent  “shot”  and  “splash”  were  heard  over  the  com¬ 
munication  network  as  the  artillery  hit  the  designated  locations.  BBS  artillery  effectively 
destroyed  and/or  mobility  killed  SIMNET  tank  simulators. 

d.  BBS  minefields  were  emplaced  and  SIMNET  tank  simulators  were  able  to  view  the  minefield 
markers  and  detonate  the  mines  (there  is  still  a  problem  with  the  lethality  of  the  mines, 
although  there  have  been  a  few  mobility  kills  and  destroyed  vehicles).  BBS  minefields  were 
breached  and  the  subsequent  breach  markers  were  observed  in  SIMNET. 

e.  SIMNET  tank  simulators  were  able  to  pull  up  next  to  BBS  fuel  tankers  and  cargo  trucks  and 
receive  the  appropriate  fuel  and  ammo  resupply. 

f.  BBS  aircraft  (fixed  and  rotary  wing)  engaged  and  destroyed  SIMNET  tank  simulators. 

g.  BBS  air  defense  vehicles  engaged  and  destroyed  helicopter  simulators  being  flown  at  Ft. 
Rucker,  Alabama,  and  engaged  and  destroyed  the  Falcon  Star  (F-16)  simulator  being  flown  at 
the  STOW-E  Evaluation  and  Analysis  Facility  (SEAF)  in  Grafenwoehr. 

h.  SIMNET  tank  simulators  saw  BBS  aggregate  units  as  individual  vehicles  and  engaged  and 
destroyed  BBS  individual  vehicles.  The  BBS  operators  saw  that  they  had  lost  vehicles  as  a 
result  of  the  engagement,  thus  reducing  the  combat  strength  of  the  BBS  aggregate  unit. 

i.  Ft.  Rucker  helicopter  simulators  saw  BBS  aggregate  units  as  individual  vehicles  and  engaged 
and  destroyed  BBS  vehicles.  Ft.  Rucker  helicopters  also  engaged  and  destroyed  BBS  aircraft 
including  friendly  fire  on  a  BBS  A-10. 
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j.  Falcon  Star  simulator  engaged  and  destroyed  BBS  vehicles. 

k.  CMTC-IS  fired  artillery  and  destroyed  deaggregated  BBS  vehicles. 

Another  achievement  was  the  ability  to  meet  last-minute  changing  requirements  in  order  to  use  the 
system  (with  its  faults)  in  an  operational  training  exercise  that  was  deemed  a  success. 

A  sometimes  overlooked  BBS/SIMNET  achievement  was  that  the  interface  is  actually  an  interface 
to  DIS,  allowing  interactions  with  any  other  DIS-capable  system. 

The  final  success  was  the  ability  to  upgrade  the  interface  from  testing  with  company-size  forces  in 
February  ’94  to  brigade-size  forces  for  STOW-E.  This  included  having  the  ability  to  expand  to  mul¬ 
tiple  SAF  engines  (10  is  the  maximum  to-date);  handling  over  1000  entities;  sending  out  AggPDUs 
to  include  information  on  all  BBS  units  (not  just  the  deaggregated  units);  expanding  to  over  20  BBS 
workstations;  improving  recovery  time  by  a  factor  of  10;  and  making  significant  architecture  changes 
of  adding  more  processor  cards,  shared  memory,  and  a  hard  disk  for  the  terrain  database.  These  were 
relatively  quick  changes  to  expanding  requirements  and  are  considered  significant  and  important 
accomplishments. 

3.1.7  BBS  STOW-E  Issues 

3.1. 7.1  Fixes  and  Fine  Tuning.  Several  changes  were  made  since  the  program  review  in  Septem¬ 
ber  1994.  They  are  discussed  as  follows: 

a.  Internal  UO  protocol:  This  fix  was  implemented  in  SIMCON  and  the  AIU  to  send  out  Unins¬ 
tantiated  Objects  (UOs)  on  all  objects  when  coming  up  so  that  the  Brigade  Operations  Display 
and  AAR  System  (BODAS)  would  get  all  UOs  before  game  start. 

b.  Bumper  Numbers  extension:  This  was  expanded  to  include  unique  marking  text  from 
CMTC-IS  and  Falcon  Star.  The  extension  maps  to  the  marking  field  in  the  Entity  State  PDU 
(ESPDU)  and  now  equals  DIS  marking  field  size. 

c.  Translation  (ATU  and  AIU):  An  unused  field  of  the  Detonation  PDU  was  used  to  transfer 
information  (not  currently  passed  by  DIS)  for  the  SIMNET  Impact  PDU.  This  was  done  to  get 
better  weapons  effectiveness  for  Hellfire  and  30-mm.  The  parameters  passed  were  trajectory 
(Hellfire),  directionality  (30-mm),  momentum,  and  energy.  The  three  impacts  per  fire,  a  prob¬ 
lem  due  to  the  unique  way  SIMNET  was  handling  impacts  through  the  association  PDU,  was 
fixed.  The  problem  of  receiving  some  “unknown  to  SAF”  munitions  mappings  was  fixed  by 
mapping  the  unknown  munitions  to  known  SAF  munitions.  Some  parameters  in  the  SIMNET 
Vehicle  Appearance  PDU  were  not  being  passed  through  DIS.  These  were  fixed  by  setting  the 
vehicle  class  to  get  the  BMP  turrets  to  rotate  in  the  direction  of  firing  and  by  setting  engine 
speed  to  get  the  helicopter  rotors  turning. 

d.  SIMCON:  The  direct  fire  message  was  not  being  generated;  this  was  corrected.  Some  new 
reports  were  created  including  internal  error  reporting  for  debugging  purposes  and  a  listing  for 
the  BBS  operator  to  correlate  BBS  Unit  IDs  with  BBS  Unit  Names  and  with  their  mapped 
SIMNET  or  DIS  bumper  numbers.  A  UO  delay  was  added  to  allow  the  UO  to  be  downloaded 
and  sent  out  first  before  units  get  instantiated.  The  delay  is  currently  set  at  1  minute. 

e.  SAF  4.3.3:  SAF  terrain  obstacles  (tree  canopy  avoidance,  water  hazards,  and  soil  types)  were 
removed  (or  “turned  off’)  to  meet  the  criteria  of  moving  BBS  units  through  an  area  and  meet¬ 
ing  specific  phase  line  times.  There  were  numerous  bugs  fixed  in  SAF  4.3.3  that  formerly 
caused  it  to  crash.  No  SAF  core  dumps  were  noticed  during  STOW-E. 
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f.  BBS  OPFOR  Tent  (LAN  Fix):  The  OPFOR  tent  was  put  up  after  Functional  Validation  #2. 
After  having  severe  movement  problems,  it  was  discovered  that  60  to  75%  of  the  data  was 
being  lost  going  to  the  tent.  A  DEC  DELNI  (a  multiplexing  device  for  BBS)  was  causing  the 
bottleneck.  After  it  was  removed  from  the  loop,  100%  of  the  data  got  through. 

g.  Stealth  View:  The  Stealth  GT110  was  an  immense  help,  and  its  addition  to  the  BBS  setup  at 
Hohenfels  provided  invaluable  debugging  information  on  why  vehicles  were  getting  stuck.  It 
also  provided  a  great  visual  cue  for  preparing  movement  legs  for  BBS  unit  movement  and  for 
monitoring  BBS  units  moving  through  the  terrain  during  the  exercise. 

3.1.8  AIU/SAF  Issues 

The  following  is  a  discussion  of  issues  that  came  up  over  the  final  4  to  6  months. 

3.1 .8.1  SAF  Delete  Entries.  The  SAF  4.3.3  code  had  a  bug  that  does  not  allow  deletion  of  entries 
from  a  hash  table.  Thus,  the  hash  table  eventually  fills  up  (to  a  maximum  of  2048  entities)  and  then 
the  process  stops.  This  was  discovered  only  2  days  prior  to  STOW-E.  Prior  to  that,  SAF  crashes 
were  thought  to  be  solely  related  to  excessive  numbers  of  entities.  During  the  exercise,  an  attempt 
was  made  to  maintain  a  stable  SOI  by  using  the  relocatable  SOI  feature  of  SIMCON.  This  seemed  to 
work  to  a  certain  degree,  but  eventually  the  table  would  still  fill  up.  The  size  of  the  table  was  moni¬ 
tored  to  predict  when  the  system  would  go  down- and  to  take  advantage  of  any  lulls  or  pauses  in  the 
exercise  in  order  to  restart.  Possible  fixes  to  avoid  a  crash  include  allowing  deletion  of  entries,  resiz¬ 
ing  the  hash  table,  or  generating  a  warning  for  the  operator  as  the  table  fills.  (Short  term) 

3.1 .8.2  SAF  Movement.  There  were  several  problems  with  SAF  movement: 

a.  The  aircraft  tended  to  wander  off  of  their  courses  frequently  for  no  apparent  reason.  More 
investigation  is  required  to  determine  why  it  is  happening  and  what  can  be  done  about  it.  (Mid 
term) 

b.  Every  time  the  Travel-On  Road  function  was  implemented,  SAF  engines  crashed.  This  prob¬ 
lem  also  needs  more  investigation.  (Mid  term) 

c.  Water  hazards  have  always  been  a  problem.  Vehicles  got  stuck,  eventually  got  through,  and 
then  turned  around  and  went  right  back  into  the  water.  This  resulted  in  unacceptable  time 
delay  and  confusion  for  the  BBS  operators.  BBS  technicians  have  removed  most  of  the 
unfordable  water  hazards  from  their  own  BBS  digital  database.  For  STOW-E,  the  water  haz¬ 
ards  were  removed  from  the  SAF.  (Mid  term) 

d.  Tree  canopies  also  caused  problems.  One  was  a  “cul-de-sac”  problem:  an  indention  in  a 
canopy  where  the  vehicles  seemed  to  keep  looping  and  never  get  out.  Other  problems  were 
with  the  roundabout  way  of.  getting  around  canopies  and  with  the  troubles  caused  when  cano¬ 
pies  were  very  close  together.  These  problems  caused  severe  movement  problems  and  time 
delays  for  BBS  units;  thereby  requiring  that  the  tree  canopy  avoidance  algorithms  in  SAF  were 
turned  off.  (Mid  term) 

3.1. 8.3  SAF  CS/CSS.  The  AIU  handled  red  artillery  missions,  all  artillery  dispersion,  and  all  resup¬ 
ply  functions,  not  the  SAF.  This  functionality  is,  or  will  be  available,  in  ModSAF.  (Mid  term). 

Also,  resupply  vehicles  had  unlimited  supplies;  this  could  be  fixed  in  the  short  term  by  tracking  in 
the  AIU.  (Short  term) 

3.1 .8.4  SAF  Minefields.  At  times  the  minefield  markers  appeared  to  look  different  on  different 
Stealths.  This  may  be  due  to  the  large  quantity  of  mines  and  markers,  the  update  rate  of  the  markers, 
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or  even  the  loading  of  the  different  Stealths.  (Mid  term).  Also,  the  breach  markers  can  be  used  as 
implemented  to  mark  a  breached  area,  but  the  orientation  of  the  markers  is  wrong.  There  may  be  no 
solution  to  this  problem.  (Long  term) 

3.1 .8.5  SAF  Terrain  Database.  Entities  hit  steep,  vertical  walls,  got  stuck,  and  then  start  flipping 
around.  Perhaps  there  was  a  problem  with  the  avoidance  algorithm  of  entities  and  vertical  slopes,  or 
perhaps  the  problem  is  the  actual  tdb  or  ctdb,  or  a  combination.  (Mid  term).  Also,  it  would  be  bene¬ 
ficial  to  be  able  to  easily  turn  off  certain  obstacle  avoidance  algorithms  to  meet  specific  operational 
objectives.  (Long  term) 

3.1 .8.6  SAF  Engagements.  Marksmanship  was  reduced  to  0.5  for  OPFOR  during  STOW-E,  but 
there  was  no  control  over  target  acquisition.  It  appears  that  as  soon  as  LOS  was  established,  the  SAF 
vehicles  acquired  the  target(s)  immediately  and  began  firing.  This  was  unrealistic  for  the  SIMNET 
vehicles;  thus  the  target  acquisition  parameter  needs  to  be  adjustable.  It  was  also  noted  that  detection 
ranges  for  SIMNET  and  for  BBS  need  to  be  the  same.  (Mid  term) 

3.1 .8.7  SAF  Entity  Load.  The  capability  for  more  SAF  entities  is  needed.  Right  now,  moving  to 
ModSAF  will  yield  fewer  SAF  entities.  (Long  term) 

3.1. 8.8  AIU/SAF  Unit  Names.  A  naming  convention  for  units  between  the  different  domains 
needs  to  be  established.  The  current  naming  conventions  for  CMTC-IS  and  BBS  are  different. 

There  is  still  a  problem  with  BBS’s  aggregate  units.  Some  are  split  out  after  the  game  has  started. 
This  creates  problems  with  systems  such  as  BODAS  that  are  trying  to  track  vehicles  at  an  individual 
level.  A  method  of  naming  the  BBS  individual  vehicles  and  handling  the  split  units  needs  to  be 
investigated  and  implemented,  probably  in  the  AIU,  using  marking  text  and  a  cross-reference  table. 
(Mid  term) 

3.1 .8.9  AIU/SAF  Reallocation.  If  one  or  more  SAF  engines  crash,  they  can  be  restarted  and  be 
back  running  in  seconds.  However,  if  a  SAF  engine  crashed  hard,  the  entire  system  needs  to  be 
restarted.  A  function  could  be  added  to  transfer  entities  to  another  SAF  engine,  if  that  SAF  engine 
could  handle  the  additional  load.  (Mid  term) 

3.1.8.10  AIU/SAF  SOI  Calculations.  The  SOI  calculation  should  be  moved  from  SIMCON  to  the 
AIU.  This  would  free  up  some  of  the  processing  load  created  by  SIMCON.  At  the  same  time,  the 
efficiency  of  the  SOI  calculations  could  be  increased  by  using  a  sorted  array  of  units,  and  the  meth¬ 
odology  of  the  SOI  could  be  used  to  reduce  the  total  number  of  entities  and  to  decrease  the  cascading 
effect.  (Mid  term) 

3.1.8.11  AIU  Memory.  The  memory  on  the  CPU  card  is  near  capacity.  Other  CPU  cards  with  more 
memory  could  be  purchased,  or  other  alternatives  could  be  investigated.  Also,  when  CMTC-IS  enti¬ 
ties  were  not  filtered  out,  the  flood  of  PDUs  resulted  in  fragmentation  of  memory  on  BBS  card  2. 
There  was  plenty  of  memory,  but  no  one  piece  was  big  enough  to  hold  the  rather  large  unit  data 
structure  (~12  kbytes).  Modifying  the  unit  data  structure  to  be  variably  sized  and  malloc’ed  in  pieces 
instead  of  as  one  large  chunk,  would  enable  the  AIU  to  handle  a  larger  number  of  entities  coming  in 
fromDIS.  (Midterm) 

3.1.8.12  AIU/SAF  Design  Issues.  As  the  capability  of  the  system  continues  to  be  stressed  and 
expanded,  there  may  need  to  be  a  re-evaluation  to  determine  if  the  current  design  can  reach  the  next 
plateau.  While  the  capabilities  were  rapidly  increased  from  FireStarter  to  STOW-E,  the  system  may 
be  reaching  its  limitations.  Other  alternatives  may  be  needed  to  be  investigated.  (Mid  term) 
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3.1.9  BBS/SIMCON  Issues 


Most  of  the  issues  listed  below  are  not  problems  with  the  current  system,  but  suggestions  on  how 
to  improve  the  system.  Interaction  with  BBS  was  limited  in  several  areas  due  to  the  restriction  of  not 
being  able  to  change  BBS  source  code.  In  fact,  no  changes  to  the  BBS  code  was  made  for  STOW-E. 
Some  of  the  information  to  the  BBS  operator  therefore  did  not  flow  as  smoothly  as  desired.  The  fol¬ 
lowing  is  a  discussion  of  the  most  current  issues  and  limitations: 

a.  BBS  3.0.  Convert  SIMCON  code  to  BBS  3.0  in  future.  (Short  term) 

b.  BBS  BDA.  Perform  BDA  for  artillery  and  minefields  in  SAF  for  BBS  units  in  the  SOI.  Let 
BBS  complete  the  BDA  for  SAF  initiated  damage.  (Mid  term) 

c.  BBS  Movement.  Perform  movement  calculations  only  in  the  SAF  (not  in  BBS)  for  BBS  units 
in  the  SOI,  to  reduce  the  jumping  of  icons  in  BBS.  Review  the  problem  with  units  not  follow¬ 
ing  movement  orders.  (Mid  term) 

d.  BBS  Unit  Names.  Adopt  identical  naming  conventions  across  the  various  simulation  domains. 
(Mid  term) 

e.  BBS  Enemy  Workstations.  Increase  the  number  of  OPFOR  workstations  in  a  game  to  more 
than  five  (10  minimum).  (Mid  term) 

f.  BBS  Total  Icons.  Increase  the  total  number  of  icons  in  a  game  to  above  750  (1000  minimum). 
(Mid  term) 

g.  BBS  Deagg  Flag.  Create  a  deaggregate  flag  and  keep  it  in  the  BBS  database  to  track  whether 
a  unit  is  deaggregated  or  not.  Could  use  the  deagg  flag  to  signal  functions  to  suppress  calcula¬ 
tions.  (Mid  term) 

h.  BBS  Cease  Fire.  Allow  the  BBS  commander  to  control  cease  fire  for  his  units  while  in  the 
SOI.  Currently,  it  is  done  by  setting  the  engagement  range  to  zero  and  locking  cease  fire  “on” 
in  BBS.  (Mid  term) 

i.  BBS  Shift.  Improve  the  BBS  commander’s  ability  to  move  stalled  units.  BBS  should  monitor 
movements  for  units  in  the  SOI.  The  stalled  unit  should  be  flagged  and  SHIFT  be  made  avail¬ 
able  to  the  BBS  commander.  The  SHIFT  function  does  not  currently  work  even  with  a  BBS- 
only  exercise.  (Mid  term) 

j.  BBS  LOS.  Suppress  the  LOS/Detection  calculations  between  BBS  pairs  that  are  in  the  SIM- 
NET  SOI.  (Midterm) 

k.  BBS  MTBF.  Suppress  the  Mean  Time  Between  Failure  calculations  for  a  BBS  unit  in  the  SIM- 
NET  SOI.  (Midterm) 

l.  BBS  Personnel  Counts.  Personnel  damage  assessment  was  not  always  accurate.  It  would  be 
better  to  develop  a  way  BBS  could  take  external  damage  and  process  it  according  to  the  dam¬ 
age  received.  (Mid  term) 

m.  BBS  Maintenance  and  Supply.  Allow  Maintenance  and  Supply  missions  to  be  done  from  all 
workstations.  During  STOW-E,  such  missions  had  to  be  conducted  from  specific  workstations 
because  BBS  did  not  send  the  appropriate  messages  from  all  stations.  (Mid  term) 

n.  BBS  Alerts.  The  alerts  generated  by  the  BBS  units  in  the  SOI  should  be  reviewed.  Some  alerts 
generated  by  BBS  should  be  removed  (i.e.,  detection  alerts),  and  should  be  generated  from 
data  received  from  the  SAF.  Some  redundant  alerts  should  be  paired  down  (i.e.,  receiving 
direct  fire).  (Mid  term) 
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o.  BBS  Performance  Considerations.  Several  methods  of  tracking  BBS  network  and  memory 
activity  were  developed.  Each  method  brought  increasingly  better  performance,  but  none  was 
very  efficient.  More  work  needs  to  be  done  in  this  area.  Some  of  the  problem  was  addressed 
by  using  Micro  VAX  31 00-90s,  which  greatly  increased  response  time.  Any  platform  slower 
than  a  Micro  VAX  3100-40  would  not  have  acceptable  performance. 

p.  BBS  Terrain  Database.  The  BBS  STOW-E  digital  database  was  not  consistent  with  the  pre¬ 
vious  BBS  digital  database  for  that  area,  although  correlation  appeared  within  tolerances. 
Obstacles  were  scattered  throughout  the  database  with  many  discontinuities. 

3.1.10  BBS  STOW-E  Entity  Counts 

Entity  counts  fluctuated  depending  on  the  training  mission.  Total  entities  ranged  from  1163  to 
1637  entities.  BBS-generated  entities  ranged  from  a  low  of  535  entities  to  a  high  of  1017  entities. 
The  BBS  735  icon  count  on  the  Movement-To-Contact  mission  was  larger  than  any  other  BBS  game 
that  BBS  Warlord  had  ever  run. 

UOs  were  also  being  sent  out,  and  tools  were  developed  on  November  4th  and  5th  to  help  monitor 
uninstantiated  objects  and  the  total  number  of  entities  they  represented.  The  total  number  of  BBS 
entities  being  represented  by  UOs  plus  the  total  number  of  BBS  entities  on  DIS  equaled  the  total 
number  of  entities  in  the  BBS  database  for  that  mission. 

BBS  had  2800  entities  ready  to  map  through  AggPDUs,  and  if  everything  in  the  BBS  database  had 
been  split  out  it  would  have  equaled  4400  entities.  Upon  finding  out  that  BOD  AS  had  room  for  only 
2500  (external)  entities,  the  entities  were  reduced  to  under  2500  (i.e.,  2182  on  6  November),  and  the 
operators  were  told  that  no  splits  were  allowed.  As  it  turned  out,  there  were  probably  less  than  100 
new  vehicles  created  by  splits  each  day,  but  other  conditions  existed  that  pushed  the  count  to  2500 
plus. 

One  such  condition  was  that  anytime  something  went  in  and  out  of  the  SOI,  it  took  up  more  slots, 
and  anytime  a  SAF  engine  went  down,  more  slots  were  taken.  Thus,  in  order  to  regulate  the  fluctua¬ 
tion  of  entities,  the  relocatable  SOI  was  placed  at  specific  locations  where  engagements  would  occur, 
rather  than  immediately  mapping  in  all  DIS  vehicles.  This  procedure  was  a  successful  attempt  to 
keep  from  filling  up  the  SAF  engine  hash  table  and  to  help  BODAS  from  filling  up  its  slots. 

Fast  movers  (aircraft)  caused  the  most  concern  in  fluctuating  entity  counts.  There  was  some  con¬ 
trol  over  the  fluctuation  with  respect  to  external  fast  movers  (Rucker  and  Falcon  Star),  but  there  was 
no  control  over  BBS  fast  movers  who  became  the  biggest  problem. 

Also,  having  the  BBS  Blue/BBS  Red  battle  first,  and  then  moving  the  SIMNET  battalion  through 
the  rear  echelons  of  the  BBS  Blue  battalion,  caused  a  lot  of  seemingly  unnecessary  instantiations  that 
began  filling  up  tables  prematurely.  Switching  the  BBS  Blue  battalion  and  the  SIMNET  battalion 
may  have  worked  better;  however,  it  may  not  have  satisfied  the  tactical  mission. 

The  SAF  engine  was  the  limiting  factor  in  entity-count  capacity.  To  allow  play  in  both  the  BBS 
and  SIMNET  environments  without  taxing  the  capacity  of  either  the  SAF  engines  or  the  networks,  a 
method  of  limiting  the  number  of  BBS  entities  in  SIMNET  play  was  developed  called  the  SOI 
model.  The  supposition  was  that  a  simulator  would  have  an  SOI  around  it.  Any  BBS  unit  that  came 
within  that  SOI  would  then  be  deaggregated.  When  that  same  unit  was  far  enough  away,  it  would  be 
reaggregated.  A  padding  was  set  up  to  keep  the  unit  from  “riding”  the  SOI  boundary  and  constantly 
being  deaggregated  and  then  reaggregated.  Trying  to  fine-tune  this  SOI  value  was  not  very  effective 
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because  differing  weapon  platforms  could  fire  from  distances  ranging  from  1500  m  to  10  km,  so  a 
variable  SOI  value  was  developed.  Finally,  the  SOI  boundary  value  was  calculated  as  follows: 

SOI  entry  =  (BBS  maximum  range)  +  (possible  distance  covered  in  5  seconds)  +  padding, 

SOI  exit  =  SOI  entry  +  exit  padding, 

where  the  padding  for  both  the  entry  and  exit  of  the  SOI  was  user-definable  and  changeable  during 
the  exercise.  A  series  of  “relocatable”  SOI  values  was  defined  allowing  the  user  to  create  virtual 
“points  of  interest.” 

Even  with  the  SOI,  cascading  of  deaggregated  units  was  substantial,  because  a  deaggregated  BBS 
Blue  unit  would  subsequently  deaggregate  a  BBS  Red  unit  if  it  were  close  enough,  and  so  on. 

3.1.11  BBS  STOW-E  PDUs 

The  AIU  and  ATU  used  the  following  PDUs: 

Entity  State  (ES);  Fire;  Detonation;  Collision;  Resupply  (ServiceRequest,  ResupplyOffer,  Resup- 
plyReceived);  Marker;  SIMNETStealth;  and  Aggregate  PDUs. 

The  Collision  PDUs  from  our  site  were  not  transmitted  onto  the  DIS  network  in  an  effort  to  reduce 
the  packet  load  sent  to  the  SIMNET  site. 

Aggregate  PDUs  were  also  being  sent  that  described  the  entities  that  the  BBS  units  represented. 
Modifications  to  the  Aggregate  PDU  included  the  addition  of  the  Entity  Appearance  field  so  that 
members  of  an  aggregate  unit  could  be  described  more  fully.  This  enabled  portraying  combat  power 
of  an  aggregate  unit  being  generated  by  BBS.  The  aggregate  Unit  Name  field  was  added  to  pass 
along  the  hierarchical  name  that  the  BBS  operators  used  when  referencing  an  aggregate  unit.  The 
Aggregate  PDUs  were  also  being  used  by  a  simulation  developed  by  Coleman  Research  Corporation 
and  by  BOD  AS. 

3.1.12  BBS  STOW-E  Lessons  Learned 

There  were  many  significant  lessons  learned  during  STOW-E: 

A  Functional  Validation  (FV)  dry  run  at  least  1  month  prior  to  the  exercise  is  essential. 

There  should  be  no  new  system  requirements  imposed  on  a  system  after  the  FV.  There  were  sev¬ 
eral  requirements  that  continued  to  change  even  through  FV3,  making  it  extremely  difficult  to  com¬ 
ply. 

All  systems  that  are  going  to  be  used  or  have  a  major  impact  on  the  exercise  should  be  tested  dur¬ 
ing  the  FV. 

The  Operational  user  needs  to  test  the  system  during  the  FV  in  the  same  manner  he  will  use  it  for 
the  final  exercise.  Not  having  the  same  BBS  OPFOR  and  BLUFOR  teams  for  the  dry  run  (FV2)  as 
for  the  exercise,  and  not  having  the  full  complement  of  soldiers  in  BBS  and  SIMNET  simulators 
moving  around,  resulted  in  not  being  able  to  stress  the  system  appropriately  before  the  exercise.  Hav¬ 
ing  the  OPFOR  commander  (who  had  no  experience  with  the  system)  use  the  system  for  the  first 
time  only  a  week  before  the  exercise,  almost  resulted  in  no  system  being  used. 

The  criteria  that  determine  whether  the  system  will  be  used  need  to  be  defined  prior  to  the  FV. 

The  OPFOR  commander  arrived  one  day  and  said  he  would  use  the  system  the  next  day  and  make  a 
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determination  if  it  would  fulfill  his  requirements.  Then,  during  testing  the  next  day,  the  criterion  was 
whether  or  not  he  could  move  his  units  in  a  prescribed  fashion  and  time  through  specific  phase  lines. 
The  result  of  the  test  was  a  recommendation  to  not  use  the  BBS/SIMNET  link  in  STOW-E  (a  week 
before  the  exercise).  Why?  Because  units  had  gotten  stuck  in  water  (a  known  limitation),  and  units 
had  wandered  around  tree  lines  (another  known  limitation),  making  them  late  to  the  phase  lines. 
Some  other  problems  were  due  to  the  75%  data  loss  to  the  OPFOR  tent  (which  had  not  yet  been  dis¬ 
covered)  and  the  new  BBS  STOW-E  database  that  had  obstacles  in  it  that  the  BBS  operators  weren’t 
accustomed  to  maneuvering  around.  Given  a  second  chance,  the  data-loss  problem  was  solved,  some 
changes  were  made  to  the  SAF  code,  and  the  system  passed  all  of  the  imposed  criteria. 

Major  subcomponents  need  to  be  tested  during  the  FV.  The  terrain  database  changes  for  both  the 
SAF  ctdb  and  the  BBS  digital  database  caused  some  added  stress  down  the  stretch.  The  BBS  opera¬ 
tors  just  did  not  have  enough  time  to  use  the  new  database  prior  to  the  exercise. 

Configuration  needs  to  be  “locked  in”  during  the  FV.  While  the  OPFOR  tent  worked  out  well,  it 
needed  to  be  in  place  before  FV2  so  that  the  problems  described  above  could  have  been  sorted  out 
before  the  last  week. 

The  Stealth  view  was  an  immense  help  and  would  have  been  very  beneficial  during  the  FV.  In 
fact,  it  would  have  saved  a  lot  of  time  and  effort  if  it  had  been  present  during  lab  testing.  Its  addition 
to  the  BBS  setup  at  Hohenfels  a  week  and  a  half  before  the  exercise  provided  invaluable  debugging 
information  on  why  vehicles  were  getting  stuck,  provided  a  great  visual  cue  for  preparing  movement 
legs  for  BBS  unit  movement,  and  displayed  BBS  units  moving  through  the  terrain  during  the  exer¬ 
cise.  The  Stealth  operator  would  help  the  unit  prepare  its  mission  by  doing  a  flyover  of  the  proposed 
BBS  movement  route,  then,  during  the  exercise,  would  give  direction  to  units  that  got  stuck  or  had 
other  problems.  Many  workhours  could  have  been  spent  more  productively  if  there  had  been  a 
Stealth  at  NRaD  for  testing. 

SAF  technical  expertise  should  be  available  for  troubleshooting  during  operational  use  of  the  sys¬ 
tem.  In  the  future,  if  SAF  code  is  used,  technical  support  should  be  available  to  answer  operators’ 
questions  (e.g.,  Can  the  hash  table  be  fixed?  Why  is  it  crashing  on  “travel-on  road”?  How  is  water 
turned  off?  How  do  you  turn  the  tree  canopies  off?  Why  do  the  aircraft  wander  so  much?,  etc.). 

Exercise  control  needs  to  be  well-coordinated  with  the  exercise  commanders.  At  times  there 
seemed  to  be  some  sort  of  disconnect  between  exercise  control  in  the  SEAF  and  the  exercise  going 
on  in  Hohenfels.  In  some  instances,  operational  questions  were  asked  of  Hohenfels  that  should  have 
been  directed  to  the  operational  side  of  the  house.  The  SEAF  exercise  control  was  on  a  schedule  that 
didn’t  seem  to  always  coincide  with  the  schedule  in  the  “box”  at  BBS.  Exercise  control  should  also 
be  practiced  during  the  FV  since  it  did  seem  to  improve  each  day. 

All  SEAF/SIMNET  personnel  should  have  been  required  to  tour  Hohenfels  (CMTC-IS  and  BBS) 
to  get  a  better  perspective  of  the  training  exercise  as  experienced  by  the  soldier. 

3.1.13  The  BBS  STOW-E  Transition 

The  transition  of  the  aggregation/deaggregation  technology  provided  by  the  BBS/SIMNET  inter¬ 
face  is  likely  to  begin  shortly  as  a  component  of  the  Prairie  Warrior  ’95  exercise.  It  is  expected 
that  there  will  be  a  short-term  (4  months’)  transition  from  BBS  2.3.2  to  BBS  3.0,  and  a  mid-term 
(8  months’)  transition  from  current  AIU/SAF  4.3.3  capabilities  to  the  AIU/ModSAF  1.2. 

The  BBS/ModSAF  effort  is  scheduled  for  its  first  System  Integration  Test  (SIT)  in  March  1995. 
Many  problems  will  be  identified,  and  a  report  on  status  and  proposed  schedule  to  completion  will  be 
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written.  The  focus  of  the  effort  is  moving  functionality  to  the  AIU,  and  testing  with  the  complete 
system.  The  current  problem  looming  on  the  horizon  is  still  how  to  get  more  entities  per  SAF  engine. 
Estimates  of  30  to  40  vehicles  per  SAF  (ModSAF)  engine  are  still  being  observed. 

3.2  DEFENSE  SIMULATION  INTERNET 

3.2.1  Introduction 

The  Defense  Simulation  Internet  (DSI)  is  an  Internet  Protocol  (IP)  based  network  that  provides 
real-time  simulation  and  video  teleconferencing,  to  approximately  100  subscribers  worldwide.  The 
DSI  uses  the  Stream  Protocol  (SP)  to  accommodate  real-time  applications  and  support  bandwidth 
reservation  and  multicast  capability. 

As  part  of  the  DSI’s  Phase  I  Upgrade,  the  DSI’s  CONUS  backbone  is  now  composed  of  Wellfleet 
Concentrator  Node  (CN)  and  Link  Node  (LN)  routers.  The  CN  routers  are  interconnected  by  a  cir¬ 
cuit  group  of  four  Tls,  at  nine  hub  locations  on  the  network  backbone.  Each  T-l  has  a  bandwidth  of 
approximately  1.5  Mbps  minus  overhead.  The  CN  hardware  supports  up  to  52  local  area  and  wide 
area  network  (LAN/WAN)  connections  with  an  aggregate  packet  forwarding  rate  of  188,000  packets 
per  second  (pps).  The  LN  hardware  supports  up  to  16  LAN/WAN  connections  with  an  aggregate 
packet  forwarding  rate  of  58,000  pps.  The  Wellfleet  routers  provide  enhanced  performance  includ¬ 
ing  greater  reliability  and  higher  throughput,  expanded  connectivity  for  DSI  users,  and  increased 
bandwidth  to  meet  growing  user  requirements.  The  Phase  1  Backbone  architecture  uses  frame  relay 
as  the  data  link  protocol  and  Open  Shortest  Path  First  as  the  routing  protocol. 

The  DSI  played  a  major  role  in  supporting  the  communications  requirements  for  STOW-E. 
STOW-E  incorporated  13  DSI  sites  in  the  CONUS,  Germany,  and  England.  The  classification  of  the 
exercise  was  a  combination  of  SECRET/NOFORN  and  US1. 

3.2.2  Challenges 

To  support  a  seamless  battle  simulation  for  STOW-E,  DSI  required  a  large  bandwidth  and  robust 
topology.  Various  network  components  were  upgraded  to  increase  available  bandwidth.  In  addition, 
augmenting  systems,  such  as  the  application  gateway,  were  developed  to  optimize  bandwidth  utiliza¬ 
tion. 

Another  challenge  that  faced  STOW-E  was  providing  interaction  between  unclassified  and  classi¬ 
fied  sites.  To  meet  this  challenge,  an  exercise  configuration  using  a  one-way  “Guard”  was  imple¬ 
mented.  This  component  injected  the  traffic  from  the  unclassified  sub-exercise  into  the  secure  sub¬ 
exercise.  As  a  result,  the  sites  in  the  secure  sub-exercise  received  all  the  traffic  in  both  the  secure 
and  unclassified  sub-exercises  without  compromising  security. 

3.2.3  DSI  Network  Management  and  Control 

During  STOW-E,  the  DSI  network  management  and  control  functions  were  performed  from  four 
locations:  the  Exercise  Network  Management  Center  (ENMC)  at  Arlington,  VA;  the  Network 
Control  Center  at  the  DSI  Customer  Service  Center  in  Leavenworth,  KS;  the  Bolt,  Beraneck,  and 
Newman  (BBN)  Network  Operations  Center  (NOC)  in  Cambridge,  MA;  and  the  SEAF  in  Grafen- 
woehr,  Germany.  The  ENMC  was  the  primary  network  management  and  control  center  during 
STOW-E. 

3.2.4  Supplemental  Connectivity 

The  Defense  Simulation  Internet  was  supplemented  for  simulation  data  transfer  by  two  subnets. 
The  first  subnet  was  DSI  “backdoor”  connections.  TACCSF  at  Kirtland  AFB  had  a  backdoor 
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connection  to  the  Pentagon;  Lakenheath  Air  Force  Simulators  were  connected  via  the  Grafenwoehr, 
Germany,  DSI  node;  the  AEGIS  Cruiser  at  Mayport  was  connected  by  way  of  the  Navy  MUTTS 
connectivity  system  from  Dam  Neck,  VA;  and  Cockpit  Simulators  at  Armstrong  Labs  in  Mesa,  AZ, 
were  connected  with  ACETEF  at  Patuxent  River,  MD.  The  second  sub-net  included  a  number  of  T-l 
and  E-l  circuits  “hardwired”  between  Grafenwoehr  and  Hohenfels,  Germany,  providing  that  connec¬ 
tion  with  over  5-Mbps  bandwidth. 

3.2.5  DSI  Results  and  Observations 

Leading  up  to  STOW-E,  Sub-System  Integration  Testing,  which  began  in  April  ’94,  indicated  that 
the  reliability  of  the  DSI  was  not  satisfactory  to  complete  STOW-E.  Reliability  was  measured  in 
terms  of  hours  scheduled  versus  hours  useable  by  simulations  to  conduct  testing.  In  the  June-July 
’94  timeframe  during  STOW-E  Sub-System  Integration  Testing,  DSI  reliability  was  approximately 
60%  to  70%.  Two  changes  were  implemented  in  late  summer/early  fall  that  increased  the  reliability 
during  final  testing  stages.  First,  it  was  decided  that  the  maturity  of  the  DSI  Phase  1  was  sufficiently 
robust  to  merit  cut  over  to  Phase  1 .  Testing  prior  to  that  timeframe  had  been  conducted  on  Phase  0. 
Phase  1  provided  improved  commercial  off-the-shelf  switches  (Wellfleet’s)  and  redundancy  in  circuit 
routing  to  the  sites.  Secondly,  it  was  decided  to  bring  onboard  the  DSI  primary  vendor  to  supple¬ 
ment  the  DSI  operations  and  maintenance  vendor  for  the  conduct  of  STOW-E.  Testing  reliability 
increased  dramatically  during  October  ’94.  For  the  execution  of  STOW-E  over  the  period  of  4  to  7 
November  1994,  during  operations  that  ran  approximately  16  hours  per  day,  reliability  of  the  DSI 
was  99%. 

Two  notes  need  to  supplement  this  apparently  superb  network  performance.  First,  the  network 
was  manned  24  hours  a  day  at  every  site  by  both  the  DSI  “manufacturer”  and  by  the  DSI  “operations 
and  maintenance”  contractor.  Second,  the  network  was  brought  down  every  night  for  maintenance 
and  was  systematically  brought  back  up.  This  process  took  2  hours  nightly.  While  the  success  of  the 
DSI  was  overwhelmingly  positive  and  a  key  factor  in  the  overall  success  of  STOW-E,  it  was  not  a 
hands-off  operation.  Extraordinary  effort  and  hands-on  care  were  devoted  to  the  network  throughout 
the  STOW-E  period  of  performance,  4  to  7  November  1994. 

It  should  be  pointed  out  that  while  DSI  is  equipped  to  simultaneously  handle  voice,  data,  and 
image,  during  STOW-E,  it  primarily  handled  only  data.  Tactical  and  coordination  voice  circuits 
where  handled  by  DSN  or  dial-up  lines.  There  was  a  video  teleconference  (VTC)  between  Grafen¬ 
woehr  and  Hohenfels,  but  it  was  over  a  dedicated  T1  vice  DSI.  An  occasional  VTC,  during  non¬ 
exercise  hours,  was  conducted  over  the  DSI  between  Grafenwoehr  and  IDA  in  Washington  or  WIS- 
SARD  at  Norfolk,  VA.  Over  99%  of  the  traffic  on  the  DSI  during  STOW-E  was  DIS  Protocol  Data 
Units  (PDUs).  The  average  total  scenario  load  between  4  to  7  November  1994  STOW-E  operations 
was  approximately  900  to  1 300  entities  depending  on  the  operation  for  that  day.  The  peak  each  day 
during  STOW-E  was  normally  around  1800  fully  interactive  entities.  Scenario  load  during  testing 
prior  STOW-E  did  reach  3500  entities  on  one  occasion.  The  DSI  was  reliable  during  all  of  these  cir¬ 
cumstances. 

3.3  SCALEABILITY 
3.3.1  Goal 

The  goal  of  the  Scaleability  program  is  to  support  the  evolution  of  DIS  technology  by  pushing 
back  the  limitations  on  the  number  of  entities  that  can  participate  in  an  exercise.  Since  the  load  on 
the  simulation  network  grows  in  proportion  to  the  entity  count,  the  load  will  always,  at  some  point. 
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exceed  the  available  bandwidth.  To  push  back  this  boundary,  techniques  have  been  developed  to 
increase  the  density  of  information  that  can  be  transmitted  across  a  given  bandwidth. 

3.3.2  Challenge 

For  STOW-E,  approximately  1800  entities  were  generated  at  sites  around  the  world.  Because  of 
the  geometry  of  the  sites  on  the  network,  high-traffic  segments  of  the  DSI  needed  to  support  a  traffic 
load  of  4.9  Mbps.  The  DSI  was  limited  to  a  throughput  of  1.1  Mbps,  however,  so  the  offered  load  to 
the  network  had  to  be  reduced  by  approximately  80%. 

Offered  Load:  4.9  Mbps 

Available  Bandwidth:  1.1  Mbps 

Required  Reduction  in  B/W  Demand:  -80% 

3.3.3  Concept 

To  accomplish  the  required  reduction  in  bandwidth  demand,  a  means  was  developed  to  transpar¬ 
ently  determine  whether  generated  data  was  of  value  to  other  sites  in  the  exercise.  If  the  data  was 
required  by  another  site,  it  was  passed  on  to  the  Wide  Area  Network  (WAN);  if  not,  the  WAN  never 
saw  this  additional  and  unnecessary  load.  This  decision-making  function  was  housed  in  a  computer 
on  each  LAN  referred  to  as  an  Application  Gateway  (AG).  The  AG  further  reduced  the  offered  load 
to  the  WAN  by  reformatting  the  data  to  achieve  more  efficient  transmissions. 

3.3.4  Implementation 

Each  aspect  of  the  Application  Gateway’s  functionality  was  embodied  by  a  specific  Bandwidth- 
demand  Reduction  Technique  (BRT).  Seven  BRTs  were  integrated  into  the  AG  and,  though  indepen¬ 
dent,  worked  in  concert  to  maximize  the  reduction  in  the  offered  load  to  the  network.  Each  BRT  is 
outlined  below. 

3.3.4. 1  PDU  Culling.  Data  is  exchanged  between  simulation  hosts  via  packets  called  PDU.  There 
are  a  variety  of  PDU  types,  each  designed  to  transmit  a  particular  type  of  message.  The  most  com¬ 
mon  PDU  type  is  the  Entity  State  PDU  (ESPDU)  that  relays  information  about  the  location  and 
appearance  of  a  simulated  entity.  PDU  Culling  discards  all  non-DIS  PDUs  and  collision  traffic 
PDUs,  in  particular,  as  well  as  ESPDUs  that  are  not  within  the  playbox  boundaries.  The  collision 
traffic  to  be  excluded  is  composed  of  the  Collision  PDUs  in  which  the  Issuing  Entity  ID  Site  matches 
the  Colliding  Entity  ID  Site  (i.e.,  local  collisions).  PDU  Culling  routes  qualifying  ESPDUs  to  the 
Grid  Filtering  Algorithm  for  further  processing.  All  non-ESPDUs  are  transmitted  because  of  their 
negligible  contribution  to  the  overall  load. 

3.3.4.2  Grid  Filtering.  A  playbox  area  for  the  current  exercise  is  determined  upon  startup  of  the 
AG.  The  playbox  is  divided  into  squares  representing  grids  that  can  be  referenced  by  row  and  col¬ 
umn.  The  width  of  the  grid  square  is  determined  at  startup  with  a  minimum  size  of  3  km.  Each  AG 
broadcasts  Grid  Subscribe  PDUs  to  indicate  Grids  of  Interest  (GOI)  based  on  the  union  of  the 
Regions  of  Interest  (ROI)  of  locally  generated  entities. 

A  Comprehensive  Union  (CU)  of  GOIs  is  calculated  in  the  Grid  Subscription  Processor.  PDUs 
that  pass  the  initial  PDU  Culling  analysis  as  Entity  State  PDUs  are  assigned  a  grid  location  based  on 
their  coordinates.  If  the  grid  location  is  in  the  Comprehensive  Union,  the  PDU  is  processed  as  an 
ESPDU.  If  the  assigned  grid  location  is  not  in  the  CU,  the  PDU  is  marked  as  a  Summary  Entity  (SE) 
for  further  processing. 
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3.3.4.3  Quiescent  Entity  Determination  (QED).  QED  is  responsible  for  determining  if  an  entity 
is  inactive.  All  ESPDUs  that  are  received  from  the  Grid  Filtering  Algorithm  are  processed  by  the 
Quiescent  Entity  Determination.  The  QED  compares  the  most  recent  ESPDU  with  the  last  ESPDU 
saved  in  a  hash  table.  If  there  has  been  no  change  in  the  location,  orientation,  appearance,  or  articu¬ 
lated  parts,  the  entity  is  deemed  quiescent.  Application  Gateways  generate  ESPDUs  for  quiescent 
entities  locally,  eliminating  the  need  to  repeatedly  broadcast  unchanging  information  over  the  WAN. 

3.3.4.4  Protocol-independent  Compression  Algorithm  (PICA).  The  PICA  is  a  differential, 
lossless,  protocol-independent  compression  technique  that  can  significantly  reduce  bit  transmission 
rates  in  DIS  applications.  PICA  is  applied  only  to  ESPDUs  in  the  current  AGs.  These  PDUs,  upon 
first  receipt,  are  saved  locally  as  reference  PDUs  in  the  AGs.  Subsequent  changes  to  an  entity’s  posi¬ 
tion  or  appearance  are  sent  over  the  network  in  an  abbreviated  form  as  changes  to  the  reference-PDU 
bit  pattern  only.  The  resultant  savings  in  bandwidth  usage  is  the  difference  in  size  between  complete 
ESPDUs  and  these  smaller,  modifying  messages  sent  in  their  place. 

3.3.4.5  Bundling.  The  AG  Bundling  algorithm  collects  PDUs  and  concatenates  them  into  larger 
packets  that  can  be  transmitted  more  efficiently.  Bundled  packets  are  transmitted  when  full  (operator 
selectable  up  to  1000  bytes)  or  when  the  operator-selectable  time-out  period  has  been  reached. 

3.3.4.6  Overload  Management.  The  Overload  Management  algorithm  prevents  bottlenecks  in  the 
traffic  flow  by  dispersing,  over  time,  the  transmission  of  packets  from  an  overloaded  site  (as  opposed 
to  losing  them)  and,  if  that  action  is  insufficient,  by  intelligently  discarding  packets  according  to  their 
priority.  The  Overload  Management  algorithm  determines  the  maximum  number  of  packets  per 
second  that  should  be  allowed  for  transmission  from  the  AG.  All  participating  AG  sites  start  out 
with  equal  bandwidth  percentages,  but  these  percentages  can  be  altered  after  start-up  to  accommo¬ 
date  changing  data  flow  patterns. 

3.3.4.7  LAN  Filter.  A  Local  Union  (LU)  of  GOIs  is  computed  by  the  Grid  Filtering  function  using 
the  radar  ranges  of  the  local  simulation  entities.  This  LU  is  used  to  filter  LAN-bound  ESPDUs  and 
ESPDUs  created  from  SE  PDUs.  If  the  grid  coordinates  of  an  ESPDU  are  in  the  LU,  the  ESPDU  is 
transmitted  to  the  LAN.  The  LAN  Filter  also  eliminates  unnecessary  ESPDU  data  from  the  LAN- 
bound  streams  by  employing  an  entity  filter  (simulators  of  subsurface  entities  would  not  be  interested 
in  land  vehicles;  therefore,  land  ESPDUs  would  not  be  released  to  their  LAN).  All  non-ESPDU  DIS 
traffic  is  transmitted  to  the  LAN  without  being  filtered  since  the  potential  reduction  in  traffic  does 
not  warrant  the  processing  cost. 

3.3.5  AG  STOW-E  Results 

Table  3-1  summarizes  initial  AG  results  for  STOW-E.  (A  separate  STOW-E  data  analysis  report 
will  address  AG  performance  in  greater  detail.) 
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Table  3-1.  AG  results  for  STOW-E. 


AG  Availability 

99.6% 

Algorithm  Reduction  Factors: 

Compression 

2:1 

Grid  Filtering 

1.1:1 

PDU  Culling 

TBD* 

Quiescent  Entity  Service 

TBD* 

Bundling 

2.5:1 

Load  Leveling 

TBD* 

LAN  Filter 

N/A** 

AG  Combined  Data  Reduction  Factor 

15:1 

*  Transparent  to  user.  Awaiting  analysis  of  data. 

**  User  controllable  filter  for  LAN.  Did  not  affect  WAN  load. 

Percent  of  DSI  Bandwidth  used  during  peak  demand 
with  AG  on-line 

(Peak  was  approximately  1800  entities) 

50% 

3.3.6  STOW-E  Lessons  Learned 
3.3.6.1  Operational  issues 

a.  The  long-haul  network  must  support  file  transfers.  Developmental  software  will  always  need 
to  be  updated,  and  no  other  means  of  transfer  is  fast  enough,  convenient  enough,  or  cheap 
enough. 

b.  All  sites  should  have  a  secondary  Internet  connection  with  a  tape-drive-equipped  host  to  allow 
for  non-DSI  transfers  of  software  and  data  (a  “data  back  channel”). 

c.  Back-channel  voice  communication  links  need  to  be  provided  to  permit  technical  personnel  to 
coordinate  support  activities  off-line.  These  phones  need  to  be  located  next  to  the  host  so  that 
the  point  of  contact  doesn’t  need  to  run  back  and  forth  between  rooms  or  buildings. 

d.  Standard  Operating  Procedures  (SOPs)  are  required  for  all  operations  involving  hardware  and 
software  use  at  multiple  sites  to  ensure  that  equipment  and  applications  will  be  properly  con¬ 
figured  when  the  exercise  commences. 

e.  Every  site  must  be  manned  by  at  least  two  dedicated  technical  support  personnel  to  prevent 
fatigue  and  to  allow  for  the  management  of  unforeseen  crises. 

f.  All  operators  need  to  be  proficient  in  UNIX.  Classes  need  to  be  scheduled  well  in  advance  to 
train  all  personnel  on  the  basics  of  text  editing,  navigation  through  the  hierarchy  of  directories, 
manipulation  of  files,  use  of  peripherals  (e.g.,  tape  drives),  and  use  of  any  specialized  software 
for  the  exercise.  These  classes  must  be  mandatory.  Written  tutorials,  while  useful  and  highly 
recommended,  are  not  substitutes  for  hands-on  instruction. 

g.  Test  schedules  cannot  be  extended  over  so  many  hours  and  so  many  days  that  personnel 
become  either  mentally  or  physically  fatigued.  Tired  testers  make  stupid  mistakes  and  can’t 
troubleshoot  even  simple  problems. 

h.  To  prevent  unforeseen  problems  during  tests  and  exercises,  sites  must  be  constrained  to  gener¬ 
ate  no  more  than  their  allotted  number  of  entities.  Unexpectedly  high  data  loads,  when  already 
operating  near  network  throughput  limits,  are  a  dangerous  and  unnecessary  risk. 
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i.  Projects  of  the  magnitude  of  STOW-E  must  be  given  the  highest  priority  at  all  participating 
sites.  Intermittent  participation,  resulting  from  shared  allegiance  with  other  projects,  changes 
the  testing  parameters,  can  invalidate  data,  decreases  the  effectiveness  of  the  training  sessions, 
and  increases  the  workload  on  all  other  participants. 

j.  Sites  should  not  be  permitted  to  allow  their  corporate  LAN  to  be  connected  to  their  test  LAN. 
This  situation  floods  the  WAN  with  unwanted  data  unless  the  “promiscuous  mode”  is  turned 
off  on  the  T/20.  The  absence  of  the  promiscuous  mode  prevents  network  connectivity  from 
being  checked  with  the  Ping  program  and  prevents  the  transfer  of  software  changes  via  ftp. 

3.3.6.2  Field  Testing 

a.  Full-scale,  multisite  network  testing  of  new  software  and  procedures  must  be  begun  far  in 
advance  of  any  major  demonstration.  There  is  no  substitute  for  exercising  SOPs  and  new 
technologies  in  the  environment  where  they  are  expected  to  perform. 

b.  Behavior  of  the  long-haul  network  should  be  fully  analyzed  and  understood  prior  to  the  con¬ 
duct  of  a  major  exercise  where  additional  data  is  to  be  collected.  Without  this  information,  it  is 
nearly  impossible  to  pinpoint  the  sources  of  errors  and  anomalies. 

c.  It  is  helpful  to  run  “immediate  action  drills”  to  ensure  all  personnel  know  what  to  do  in  the 
event  of  a  computer  crash  or  other  problem  requiring  rapid  corrective  action. 

3.3.6.3  Development  Environment 

a.  If  complex  software  is  to  be  developed  in  modules,  all  modules  must  be  completed  well  in 
advance  of  the  first  scheduled  test  period.  Internal  software  conflicts  can  bring  an  otherwise 
robust  system  to  its  knees. 

b.  The  means  to  measure  the  effects  of  new  software,  both  quantitatively  and  qualitatively,  must 
be  made  available  to  the  development  team.  This  includes  data  analysis  tools,  Stealth  systems, 
and  additional  personnel  to  run  the  tests. 

c.  If  multiple  teams  are  going  to  contribute  to  the  final  software  product,  periods  of  testing  with 
all  parties  at  one  site  are  essential. 

3.3.6.4  Algorithms 

a.  All  unnecessary  processes  (e.g.,  daemons)  running  on  the  AG  host  must  be  killed  before  bring¬ 
ing  up  the  AG  to  avoid  conflicts. 

b.  The  AG’s  built-in  debugging  menus  were  very  helpful.  All  future  versions  should  be  similarly 
equipped. 

c.  Future  versions  of  the  AG  should  have  built-in  statistics-gathering  capability. 

d.  Reallocation  of  bandwidth  within  the  Load  Leveling  algorithm  should  be  automatic  to  improve 
responsiveness. 

e.  The  configuration  of  the  AG  control  panel  should  be  able  to  be  saved  to  speed  up  future 
restarts. 

f.  Effectiveness  of  the  QED  could  possibly  be  improved  if  the  constraints  were  relaxed.  In  other 
words,  allow  the  QED  to  handle  a  tank  that  is  standing  still  even  though  its  turret  is  rotating  in 
a  repetitive  manner.  (CPU  demand  must  be  considered.) 

g.  Additional  bandwidth  savings  might  be  realized  by  extending  compression  techniques  to  other 
than  ESPDUs  (the  remaining  10%  of  PDUs). 
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h.  Broadcast  Grid  Filtering  must  be  replaced  by  Dynamic  Grid  Subscription/Multicasting  as  soon 
as  the  long-haul  network  will  support  it. 

i.  Algorithms  should  be  kept  as  simple  as  possible  so  that  lower  cost  CPUs  can  be  employed. 

j.  A  “crisis  mode”  should  be  built  into  the  AG  to  handle  data  spikes.  One  solution  might  be  to 
drop  every  other  PDU  for  a  specified  period  until  the  data  load  returns  to  normal  or  the  algo¬ 
rithms  can  ramp  up  to  the  demand. 

k.  A  graphical  user  interface  (GUI)  would  allow  non-UNIX-proficient  operators  to  control  the 
functions  of  the  AG  with  less  training  and  with  more  assurance.  This  feature  might  include  a 
graphical  status  display  and  a  display  of  performance  statistics.  (CPU  demand  must  be  consid¬ 
ered.) 

l.  In  selecting  candidate  scaling  algorithms,  they  must  be  analyzed  for  their  effect  on  simulation 
validity. 

3.3.6.5  Local  Area  Networks.  While  the  AG  provided  the  means  to  scale  the  long-haul  network 
bandwidth  to  operate  within  its  capacity,  it  did  not  address  management  of  the  LANs.  Legacy  sys¬ 
tems,  tools  such  as  SIMNET  at  Grafenwoehr,  Germany,  and  Plan  View  Displays  at  nearly  all  sites 
were  not  equipped  to  handle  traffic  loads  on  the  order  of  STOW-E.  For  example,  SIMNET  crashed 
when  LAN  loads  exceeded  roughly  1000  entities, .and  Plan  View  Displays  could  not  keep  up  with 
screen  refresh  demands  at  these  loads.  A  key  lesson  learned  is  that  while  the  AG  solved  the  WAN 
issue  for  STOW-E,  significant  attention  must  be  given  to  LAN  and  legacy  system  capacities  for 
future  STOW  demonstrations/exercises.  A  LAN  manager  or  simulator  preprocessor  should  be  con¬ 
sidered. 

3.4  LIVE/RANGE  INSTRUMENTATION 

The  STOW-E  program  demonstrated  critical  simulation  technologies  by  integrating  live,  virtual, 
and  constructive  forces  into  a  seamless  electronic  battlefield.  To  assist  in  achieving  this  capability, 
live  forces  from  instrumented  ranges  were  integrated  via  DIS  during  STOW-E. 

Live  systems  encounter  different  challenges  than  virtual  and  constructive  systems.  Some  of  the 
challenges  particular  to  live  systems  include  occasional  position  inaccuracy  and  loss  of  connectivity, 
limited  bandwidth  between  the  range  and  central  instrumentation  system,  data  latency,  exercise  con¬ 
trol  limitations,  differences  in  exercise  topology  between  live,  constructive,  and  virtual  systems, 
environmental  effects,  and  data  completeness. 

In  order  to  provide  the  live  element  of  STOW-E,  the  CMTC-IS,  the  TACTS,  and  USS  Hue  City 
were  integrated  to  the  DIS  network. 

3.4.1  CMTC 

3.4.1. 1  Introduction.  The  CMTC-IS,  located  in  Hohenfels,  Germany,  was  designed  and  developed 
to  support,  through  analysis  and  feedback,  U.S.  Army,  Europe  (USAEUR),  combined  arms  training. 
The  instrumented  CMTC  monitors  and  controls  maneuver  training,  produces  after-action  reviews 
(AARs),  standardizes  evaluation  of  training  performance,  and  provides  detailed  training  feedback. 

For  CMTC-IS  to  participate  in  STOW-E,  an  interface  was  designed  and  developed  to  provide  a 
gateway  to  the  DIS  network  and  thus  a  link  to  other  simulations. 

During  STOW-E,  the  CMTC-IS  BOD  AS  provided  the  CMTC-IS-to-DIS  interface,  the  DlS-to- 
brigade  operations  interface,  the  brigade-level  display  capability,  and  the  brigade-level  AAR. 
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The  entity  state  data  for  each  instrumented  player  at  CMTC-IS  is  obtained  via  the  Global  Position¬ 
ing  System  (GPS)  portion  of  the  Simulated  Area  Weapons  Effects/Multiple  Integrated  Laser  Engage¬ 
ment  System  II  (SAWE/MILES)  system.  This  data  is  then  sent  to  the  BOD  AS  Compute  Server 
where  it  is  converted  into  DIS  PDUs  and  then  transmitted  to  the  DIS  network.  DIS  PDUs  coming 
from  the  DIS  network  are  received  by  the  BOD  AS  Compute  Server  and  processed  for  display  and 
subsequent  AAR  generation.  The  BODAS  workstations  provide  dynamic  and  static  situation  dis¬ 
plays,  control  measures,  status  displays,  statistical  displays,  time  tagging  of  events,  AAR  preparation, 
reports,  alerts,  and  audio  cuts  recorded  during  the  exercise.  BODAS  workstations,  which  are  imple¬ 
mented  on  SGI  Indy  platforms,  are  also  located  at  the  Training  Analysis  Feedback  Facilities  (TAFs) 
of  CMTC,  and  the  SIMNET  and  BBS  battalion  command  stations  to  ensure  a  full  brigade-level  AAR 
is  provided. 

3.4.1. 2  STOW-E  Accomplishments.  The  CMTC  in  Hohenfels,  Germany,  was  the  first  Army 
Combat  Training  Center  to  participate  in  a  large-scale  DIS  exercise.  DIS  PDUs,  representing  live 
units  in  the  Hohenfels  Training  Area,  were  transmitted  to  the  DIS  network  for  interaction  and  display 
with  other  systems  in  Germany  and  the  CMTC-IS  provided  another  technology  first  by  offering  the 
proof  of  concept  for  a  state-of-the-art  BODAS  that  provided  the  brigade-level  AAR  during  STOW-E. 
The  combination  of  these  two  technologies  and  the  integration  of  other  DIS  systems  allowed  the  bri¬ 
gade  commander  at  CMTC-IS  to  experience  a  seamless  brigade-level  battle.  CMTC-IS  STOW-E 
accomplishments  can  be  further  described  as  follows. 

3.4. 1.2. 1  CMTC-IS-to-DIS  Interface  (transmit).  Entity  state  information  was  sent  for  each  defined 
CMTC-IS  entity  with  an  update  period  of  every  5  seconds  for  each  entity.  The  output  was  selectable 
as  on/off  without  effecting  the  BODAS  display  of  any  of  the  other  domains.  Entity  elevation  data 
was  obtained  from  a  simulation  database  instead  of  using  the  elevation  data  received  from  GPS. 

This  was  done  to  allow  the  CMTC-IS  entities  to  appear  correctly  on  other  systems,  including  3-D 
visual  displays,  using  the  same  simulation  databases.  Both  direct  and  indirect  fire  and  detonation 
events  were  sent  from  CMTC-IS  to  DIS  as  they  occurred. 

3.4. 1.2.2  DIS-to-BODAS  Interface  (receive).  DIS  PDUs  were  received,  converted  to  CMTC  data 
format,  and  mixed  with  the  data  extracted  from  CMTC-IS.  The  processed  data  included  entity  state 
data,  aggregate  data,  and  engagement  data  for  both  direct  and  indirect  fire  events.  From  this  data,  the 
brigade-level  picture  was  built  and  broadcast  to  all  BODAS  workstations  for  display  and  AAR  prep¬ 
aration. 

3.4. 1.2.3  Brigade  Exercise  Control,  Monitoring  and  AAR.  BODAS  logged  data  for  the 
CMTC-IS,  BBS,  SIMNET,  and  Aviation  Test  Bed  (AVTB)  domains  and  provided  a  brigade -level 
AAR.  Several  issues  need  to  be  resolved  before  BODAS  is  a  deliverable  system,  but  the  proof-of- 
concept  was  implemented  and  demonstrated.  The  BODAS  system  was  capable  of  brigade-level 
AAR  generation  and  presentation  and  included: 

a.  A  view  of  the  brigade  sector.  This  included  a  display  of  data  received  from  the  DIS  WAN  with 
the  primary  focus  on  data  from  BBS,  SIMNET,  AIRNET,  and  CMTC.  Displays  could  be  set 
up  at  the  desired  level,  i.e.,  brigade,  battalion,  etc.  Specific  displays  were:  (1)  situation  dis¬ 
play,  (2)  status  display,  (3)  statistical  display,  and  (4)  alert  display.  Displayed  information 
included  element  location  and  status,  as  well  as  direct  and  indirect  fire  events  from  all 
domains.  Capacities  were  increased  with  up  to  3500  entities  being  supported.  The  entity 
count  is  a  cumulative  count  and  is  divided  as  follows:  1000  for  CMTC-IS  players,  2500  for 
non-CMTC-IS  players.  Up  to  750  units,  2000  indirect  fire  targets,  and  500  scheduled  fire  mis¬ 
sions  are  supported.  Note:  The  limit  of  2500  CMTC-IS  was  quickly  exceeded  during  the 
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6  November  1994  BLUE  ATTACK  mission  and  the  7  November  1994  MOVEMENT  TO 
CONTACT/COUNTER  ATTACK. 

b.  Generation  of  control  measures.  The  analysts  could  build  new  control  measures  on  the 
BODAS  workstation  or  display  those  built  in  the  IS  system  for  tactical  force  AAR. 

c.  Creation  of  AAR  outline:  This  included  data  from  the  simulated,  constructive,  and  the  live 
domains  and  also  dynamic  and  static  digital  replays.  Replays  of  the  mixed  domain  brigade- 
level  data  were  available  anytime  throughout  the  battle.  The  BODAS  replay  data  was  stored  in 
a  highly  compressed  format  (during  FV3,  BODAS  replay  data  was  at  roughly  20  times  smaller 
than  DIS  log  data,  and  the  BODAS  replay  data  includes  the  deaggregated  BBS  units). 

3.4.1 .3  Software  Development  Issues.  Several  software  development  issues  affected  but  did  not 
prevent  successful  CMTC-IS  integration. 

3.4. 1.3. 1  CMTC-IS-to-DIS  Interface  (transmit).  For  BODAS  to  process  an  entity  count  of  3500 
entities,  limitations  were  made  on  the  processing  of  data  in  order  to  save  CPU  usage.  The  impact 
was  that  anomalies  were  noted  in  the  representation  of  CMTC-IS  entities  on  3-D  displays. 

Elevation.  A  file  containing  a  matrix  of  25-m  spacing  altitude  values,  obtained  from  S1000  library 
calls  was  used.  When  altitude  was  desired,  the  four  surrounding  altitude  points  were  retrieved  from 
memory,  and  a  bilinear  interpolation  was  performed.  This  method  has  two  known  sources  of  inaccu¬ 
racy.  The  first  is  in  the  use  of  4  points  for  interpolation  in  the  square  versus  3  points  for  interpolation 
in  a  triangle.  The  second  is  the  use  of  25-m  spacing  with  micro-terrain  accounted  for  at  only  those 
points  (and  not  in-between).  The  result  of  these  two  inaccuracies  was  that  the  elevation  of  an  entity 
was  observed  to  be  either  under  or  floating  over  terrain  features.  To  get  more  accurate  elevation 
data,  a  canned  terrain  database  (TDB)  library  call,  such  as  libctdb  or  S1000,  can  by  used  for  runtime 
retrieval.  For  example,  libctdb  uses  3  points  for  interpolation  in  a  triangle  with  125-m  spacing  with 
micro-terrain  between  points. 

Horizontal  Positioning.  CMTC-IS  entities  were  occasionally  observed  to  jump  between  points. 
Positioning  data  is  received  via  GPS.  Positions  from  CMTC-IS  were  reported  at  a  mean  10-m  error. 
Best  resolution  was  at  3  meters  with  a  worst-case  error  of  approximately  30  to  40  meters.  During 
pre-STOW-E  testing,  the  horizontal  positions  of  outgoing  CMTC-IS  entities  were  verified  to  be  com¬ 
pletely  accurate  in  accordance  with  their  GPS  reported  locations.  Therefore,  errors  in  positioning 
can  be  attributed  to  errors  in  the  GPS  fix.  No  solution  has  been  proposed  for  the  GPS  error. 

Velocity.  Velocity  was  obtained  from  instrumented  velocity  of  vehicles.  However,  velocity  is  only 
received  some  of  the  time.  BODAS  generated  DIS  PDUs  with  a  “no  dead-reckoning  algorithm” 
marker.  In  order  for  BODAS  to  dead  reckon  outgoing  entities,  velocity  will  need  to  be  derived  from 
previous  updates. 

Orientation.  Discrete  values  were  coded  for  each  10  degrees  of  heading.  However,  CMTC-IS 
entities  were  observed  to  “crab.”  This  problem  has  been  investigated,  but  a  fix  was  not  implemented 
during  STOW-E  since  adding  the  fix  would  require  bringing  the  system  down,  which  would  affect 
data  collection  for  the  AAR. 

Fires  and  Detonations.  Both  Direct  and  Indirect  Fire  and  Detonation  Events  were  sent  as  they 
were  received  from  CMTC-IS.  However,  fire  events  are  often  received  without  being  tied  to  detona¬ 
tion  events  and  vice  versa.  The  difficulty  becomes  pairing  a  fire  event  with  a  detonation.  Another 
issue  is  extracting  the  exact  number  of  rounds  fired  in  CMTC-IS.  Currently,  a  predetermined 
number  of  rounds  for  each  mission,  spread  out  between  the  artillery  players  in  the  firing  unit,  is  sent. 
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No  target  or  mission  lists  are  generated.  Because  of  the  difficulty  in  differentiating  between  direct 
and  indirect  fire,  accurate  target  or  mission  data  cannot  be  built. 

Unknown  entity  types.  Due  to  the  wide  range  of  entity  types  participating  in  the  CMTC-IS  exer¬ 
cise,  some  “Beach  Balls”  (geodesic  shapes  to  represent  unknown  entity  types)  were  observed  on  the 
3-D  displays.  In  most  cases,  this  was  a  result  of  the  3-D  display  not  having  the  appropriate  model  for 
the  entity  received.  However,  it  was  noted  that  there  were  uninstrumented  players  (i.e.,  fire  markers, 
observer/controllers)  who  were  injected  into  CMTC-IS  by  TAF  analysts.  BOD  AS  misinterpreted 
these  entities  as  valid  DIS  entities  and  mislabeled  them  as  unknown  entity  types.  Several  unsuccess¬ 
ful  attempts  were  made  to  resolve  this  intermittent  problem  prior  to  and  during  STOW-E.  A  decision 
was  made  to  live  with  this  problem  due  to  risk  to  other  functionality  in  BODAS.  This  problem  will 
continue  to  be  investigated. 

3.4. 1.3.2  DIS-to-BODAS  Interface  (receive).  The  entity  identification  included  in  the  BBS  aggre¬ 
gate  PDU  was  different  from  the  entity  identification  in  the  entity  state  PDU  when  deaggregated. 
Simply,  the  same  vehicle  would  be  assigned  another,  completely  unrelated  ID  each  time  the  BBS  unit 
was  aggregated  or  deaggregated.  The  impact  was  that  slots  were  being  used  each  time  a  new  ID  was 
received  and  the  3500  entity  limit  was  reached  well  before  3500  actual  entities  were  on  the  battle¬ 
field.  Although  an  attempt  was  made  to  patch  the  problem  on  the  receiving  end  (BODAS),  future 
development  should  be  centered  on  increasing  BODAS’  ability  to  increase  or  reallocate  unused 
entity  slots.  Also,  the  aggregate  PDU  only  incorporates  a  maximum  of  20  entities  per  AGG  PDU.  In 
the  case  where  there  are  greater  than  30  entities  in  an  aggregated  unit,  true  combat  strength  is 
reflected  incorrectly.  This  issue  requires  further  analysis. 

3.4. 1.3.3  Brigade  Exercise  Control,  Monitoring,  and  AAR.  The  BODAS  workstation  windows 
include  the  border  controls  (quit,  lower,  raise,  etc.).  The  new  operating  system  from  SGI  has 
changes  in  this  area.  This  problem  has  been  investigated,  but  the  fix  could  not  be  implemented  prior 
to  the  STOW-E  software  freeze. 

The  BODAS  workstation  has  a  small  difference  in  map  scale.  This  is  apparent  when  placing  the 
plastic  control  measure  overlay  on  the  screen  for  tracing.  This  is  a  minor  inconvenience  for  the  ana¬ 
lyst.  This  problem  has  been  investigated,  but  the  fix  was  not  implemented  prior  to  the  STOW-E  soft¬ 
ware  freeze. 

There  are  some  capabilities  of  the  BODAS  that  were  inherited  from  the  CMTC-IS  and  that  were 
not  tested.  These  are  not  mainstream  features  (archiving  and  recovery  of  exercise  data  [currently 
done  manually],  weather  status,  all  alert  filters,  etc.)  and  did  not  affect  STOW-E. 

The  new  version  of  Informix  (the  COTS  relational  database  utility)  is  not  compatible  with  the 
baseline  CMTC  code.  Informix  no  longer  sells  the  exact  product  used  for  CMTC.  This  will  require 
additional  effort  to  convert  source  code  to  be  used  by  the  new  product. 

In  order  to  time  tag  audio  at  the  BODAS  workstation,  a  link  between  the  BODAS  workstation  and 
the  CMTC-IS  VCS  is  required.  This  task  has  not  been  completed  although  a  work-around  exists  for 
the  audio  time  tags  to  be  entered  on  a  CMTC-IS  station  and  replayed  manually  in  the  BODAS  AAR 
(the  user  included  approximately  3  audio  cuts  in  brigade  AARs  this  year). 

3.4.1 .4  Future  Efforts.  Providing  the  user  with  a  turn-key  BODAS  system  should  be  the  primary 
future  effort.  The  brigade  upgrade  is  the  preferred  next  step  because  it  takes  advantage  of  the  work 
and  the  lessons  learned  on  STOW-E.  STOW-E  consisted  of  the  tangible  items  such  as  software  and 
hardware  but  also  the  knowledge  gained  by  the  many  individuals  who  made  STOW-E  work.  In  addi¬ 
tion  to  the  brigade  upgrade,  the  following  should  be  considered. 
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a.  Integration  of  the  3-D  display  into  the  AAR.  The  use  of  a  “Stealth”  3-D  display  during 
STOW-E  was  manually  synchronized  with  the  instrumented  AAR.  This  was  difficult  and 
required  additional  operators.  Automating  the  3-D  interface  with  the  AAR,  including  3-D 
replay  as  a  step  in  the  AAR,  should  be  investigated. 

b.  Automatic  definition  of  players  and  units  for  BBS  and  CMTC-IS.  This  would  use  the  DIS 
interface  to  transfer  the  task  force  unit  organization  definition  as  the  unit  moves  from  one 
training  domain  to  the  other.  Currently,  analysts  type  this  information  in  at  both  BBS  and 
CMTC-IS  for  the  same  unit.  With  an  electronic  link,  this  information  could  be  shared  and 
time  and  effort  could  be  saved. 

c.  Automatic  flag  element  change  when  an  assigned  flag  element  receives  a  kill.  When  monitor¬ 
ing  a  complete  brigade,  it  will  be  difficult  for  the  analysts  to  manually  change  the  flag  element 
when  killed  (the  flag  element  is  used  to  position  the  unit  symbol  on  the  map). 

d.  Unit  attrition  symbology  should  be  added  to  show  units  with  35%  combat  loss.  A  black  slash 
could  be  used  similar  to  a  dead-vehicle  symbol.  This  would  greatly  improve  the  display  of  the 
brigade  picture. 

e.  A  function  key  (hot  button)  for  stepping  through  the  AAR  step  is  desired.  If  the  brigade 
upgrade  is  not  immediately  contracted,  we  recommend  developing  the  BODAS  system  into  a 
turn-key  product.  The  BODAS  system  was  built  with  the  understanding  this  was  a  proof  of 
concept  demonstration,  and  it  is  not  quite  ready  as  a  product.  This  would  require  a  small  effort 
after  STOW-E.  Additional  requirements  related  to  this  may  be  the  use  of  video  in  the  BODAS 
AAR. 

3.4.2  Tactical  Aircrew  Combat  Training  System  (TACTS) 

3.4.2. 1  introduction.  The  Tactical  Aircrew  Combat  Training  System  (TACTS)  ranges  are 
advanced  training  systems  designed  to  provide  an  effective  means  to  improve  aircrew  proficiency  in 
air-to-air,  air-to-surface  combat,  and  electronic  warfare  (EW)  mission  areas.  During  a  training  mis¬ 
sion,  data  containing  information  on  the  aircraft’s  maneuvers,  employment  of  weapon  systems, 
operation  of  radio  frequency  and  computer-simulated  ground  threats,  and  the  employment  of  aircraft 
countermeasures  are  collected,  recorded,  and  displayed  for  monitoring  and  control.  The  recorded 
data  is  used  during  debrief  sessions  so  that  the  aircrew  may  recognize  weapon  envelope  boundaries, 
observe  the  results  of  simulated  missile  and  gun  employment,  and  simulate  deliveries  against  realis¬ 
tic  surface  targets/threat  emitters. 

The  primary  goal  in  STOW-E  was  to  provide  an  interface  unit  to  allow  the  ability  of  aircraft  posi¬ 
tional  data  and  weapon  release  signals  provided  by  the  TACTS  range  to  be  transformed  to  the  DIS 
protocol  to  provide  interaction  with  other  virtual  simulation  systems.  This  function  was  performed 
in  the  AIUg,  which  is  currently  on  an  SGI  Indigo2  Extreme  platform.  Development  is  ongoing  to 
provide  two-way  interaction  by  allowing  a  remote  participant  to  control  the  threat  emitters  located  on 
the  range.  This  capability  will  allow  EW-capable  aircraft  to  participate  in  the  training  opportunities 
that  are  currently  available  only  to  the  fighter  and  attack  communities. 

3.4.2.2  System  Overview.  Connectivity  of  live  aircraft  with  the  DSI  was  accomplished  via  the 
TACTS/ Air  Combat  Maneuvering  Instrumentation  (TACTS/ACMI)  air/ground  radio  frequency  (R/F) 
data  link.  The  TACTS/ACMI  system  consists  of  four  subsystems.  The  Aircraft  Instrumentation  Sub¬ 
system  (AIS),  carried  by  each  participating  aircraft,  interfaces  with  the  aircraft  and  provides  digital 
and  range  data  to  the  rest  of  the  system  via  the  Tracking  Instrumentation  Subsystem  (TIS).  The  TIS 
includes  numerous  remote  stations  and  one  or  two  master  stations  that  together  gather  data  from  each 
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AIS  and  relay  the  information  to  the  Control  and  Computation  Subsystem  (CCS).  The  TIS  also 
accepts  update  data  from  the  CCS  for  transmission  to  the  AIS  via  the  TIS  remote  stations. 

The  principal  objective  of  including  live  aircraft  in  a  seamless  simulation  is  to  define,  solve,  and 
demonstrate  the  interfacing  functionality  of  a  distributed  interactive  warfighting  environment  com¬ 
posed  of  real,  dynamic,  high-performance  objects  (tactical  aircraft)  and  simulated  objects  (aircraft, 
missiles,  etc.)  in  a  common  real/simulated  environment. 

The  TACTS/ACMI  integration  effort  required  the  development  of  the  AIUgs  to  provide  the  inter¬ 
facing  function  between  the  DSI  and  the  TACTS  range.  The  AIUgs  is  the  gateway  between  the 
TACTS/ACMI  system  and  the  ground-based  simulation  network.  The  AIUas  was  implemented  on  an 
SGI  workstation  and  has  the  following  major  functions: 

a.  Manages  the  communication  interface  with  the  DIS  network,  provides  entity  dead  reckoning, 
entity  filtering,  and  user  interface. 

b.  Manages  the  communication  interface  with  the  CCS,  processes  DIS  PDUs,  and  processes  CCS 
data  messages. 

c.  Manages  the  communication  interface  with  the  Highly  Dynamic  (HyDy)  Display  and  Debrief¬ 
ing  Subsystem  (HDDS),  processes  DIS  PDUs,  and  builds  HDDS  display  messages. 

The  AIUgs  has  three  external  hardware  interfaces  that  use  the  DIS  network  interface,  the  CCS 
interface,  and  an  HDDS  interface. 

The  HDDS  was  a  display  system  for  air  entities  both  on  the  network  and  operating  on  the  TACTS 
range.  Developed  under  the  HyDy  program,  its  major  function  was  to  provide  a  wide  area  view  of 
the  air  battle  and  air-to-ground  targeting  interactions. 

3.4.2.3  Control  and  Computation  Subsystem  (CCS)  Modifications 

3.4.2. 3. 1  Aircraft  Entities.  Modifications  to  the  CCS  source  code  to  accept  inputs  from  the  AIUgs 
were  implemented.  This  provided  for  the  capability  of  up-  and  down-linking  aircraft  from  and  to  the 
DSI.  Testing  the  capability  of  placing  an  aircraft  entity  onto  the  DSI  from  the  TACTS  subsystem  was 
limited  by  the  available  number  of  live  aircraft  available.  At  most,  there  were  two  live  aircraft  avail¬ 
able  for  this  purpose.  Both  entities  were  successfully  placed  on  the  network.  With  the  use  of  mission 
recordings  (a  playback  feature  of  the  CCS),  this  number  was  increased  to  three  aircraft.  The  full 
capability  of  TACTS,  36  live  aircraft,  could  not  be  tested  due  to  the  bandwidth  restrictions  of  the  DSI 
with  this  level  of  network  traffic. 

With  the  AIUgS-to-CCS  uplink,  problems  were  noted  when  large  numbers  of  aircraft  were  coming 
from  the  network.  When  the  system  was  tested  with  33  DSI  aircraft  and  2  threats,  the  CCS  failed  to 
maintain  updated  files  on  approximately  half  of  them,  and  even  then,  the  updating  was  not  consis¬ 
tent.  When  the  input  was  throttled  down  to  15  DIS  aircraft,  the  CCS  began  updating  all  entities  on  a 
normal  basis.  No  reason  for  this  has  been  determined. 

3.4.2.3.2  Detonation  PDUs.  Since  the  TACTS  system  scores  bomb  drops  and  determines  the 
“probability  of  kill”  under  its  own  simulation  process,  this  result  must,  in  turn,  be  translated  into  DIS. 
This  mapping  was  verified  to  be  operational.  Also,  since  the  TACTS  system  will  indicate  conditions 
where  a  target  was  partially  disabled,  the  AIUgs  was  able  to  produce  a  detonation  PDU  when  the 
accumulated  “probability  of  kill”  reached  a  specified  level. 

3.4.2. 3. 3  Conversion  from  Virtual  to  Live  Entities.  The  conversion  from  a  virtual  entity  (WIS- 
SARD  lab)  to  a  live  aircraft  (Cherry  Point)  was  tested.  Due  to  the  lack  of  a  method  to  go  between 
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these  two  types  of  entities,  this  function  could  not  be  performed  via  the  network.  Thus  in  this  area, 
all  efforts  to  turn  on  and  off  the  respective  entity  were  coordinated  by  the  operators  over  the  voice 
network. 

3A.2.3.4  Uplink  to  Aircraft  From  DSI.  The  capability  for  this  to  take  place  was  implemented  but 
not  tested  due  to  the  requirement  for  the  aircraft  on  the  TACTS  range  to  be  loaded  with  an  ALR-67 
pod.  If  this  could  have  taken  place,  the  TACTS  system  would  have  been  able  to  stimulate  the  threat 
warning  indicators  in  the  aircraft  from  other  surface-to-air  missile  (SAM)  sites  on  the  network.  This 
path  of  communication  has  been  tested  in  the  lab,  but  not  under  a  live  situation.  Data  reduction  of 
the  CCS  mission  recording  tapes  is  planned  to  be  conducted  at  a  later  date  to  determine  if  the 
information  was  present  to  drive  the  threat  warning  indicators. 

3A.2.3.5  Interaction  Between  A/C  Pilot  and  Network  Controllers.  Via  the  V4  communications 
network,  a  live  F/A-18  (Cherry  Point)  was  able  to  be  controlled  by  an  E-2C  controller  (Pax  River) 
providing  a  realistic  situation.  The  controller  was  able  to  see  the  F/A-18  on  his  tactical  displays  and 
vector  the  pilot  in  for  a  laser-guided  bomb  drop  against  a  hostile  target. 

3A.2.3.6  HDDS  Subsystem.  Beyond  the  development  of  HDDS  for  the  HyDy  Project,  HDDS 
was  modified  to  provide  support  for  the  Stealth  PDU  and  displays  for  SAM-site  type  emitters  that 
emanate  from  ships  and  submarines.  Both  of  these  were  successfully  implemented,  but  the  HDDS 
will  not  display  the  actual  ground-based  emitter. 

Since  the  HDDS  displays  an  area  of  200  by  150  nm,  and  each  Stealth  PDU  is  set  to  filter  in  66.7- 
by  75-nm  boxes,  the  HDDS  had  to  transmit  multiple  requests  to  the  AG  so  that  it  would  receive  all 
data  on  the  entities  in  its  area  of  interest.  The  HDDS  transmitted  six  requests  that  were  successfully 
processed  in  the  AG  and  enabled  the  entity  traffic  in  the  area  of  interest  to  be  passed. 

3.4.2.4  Lessons  Learned.  For  any  exercise  requiring  live  fleet  support,  it  is  imperative  to  ascer¬ 
tain  fleet  assets  early  in  the  process.  There  were  certain  capabilities  that  required  the  live  aircraft 
asset  to  be  outfitted  with  specific  equipment  that  would  enable  the  testing  of  all  of  the  capabilities 
implemented  in  the  system. 

3.4.3  USS  Hue  City  (CG  66) 

3.4.3.1  Objectives.  The  stated  primary  objective  of  the  Navy  was  to  demonstrate  the  potential  to 
train  personnel  at  all  levels,  from  individual  tactical  console  operators  up  through  the  Battle  Group 
Commander,  in  a  DIS  environment.  Additional  goals  included  exposing  the  Fleet  to  DIS  simulation 
potential,  accelerating  development  of  the  Battle  Force  Tactical  Trainer  (BFTT),  and  bench  marking 
Navy  DIS  technology  for  use  in  future  DIS  applications.  Toward  this  end,  an  active  fleet  AEGIS 
cruiser,  USS  Hue  City  (CG  66),  was  a  participant  in  STOW-E. 

3. 4.3.2  Background.  Hue  City  was  moored  at  Naval  Station  Mayport,  Florida,  during  STOW-E. 
Even  though  STOW-E  was  a  technical  demonstration  and  not  a  training  evolution  for  the  Navy,  all 
tactical  consoles  and  voice  circuits  were  manned  by  fleet  personnel. 

3.4.3.3  DSI  Connectivity.  The  DSI  network  connection  to  Hue  City  passed  from  the  DSI  node  at 
Tactical  Training  Group  Atlantic  (TACTRAGRULANT),  over  a  1 -mile-long,  fiber-optic  line  to  the 
BFTT  shore  site,  at  Fleet  Combat  Training  Center  Atlantic  (FCTCLANT),  Dam  Neck,  Virginia. 

From  there,  a  T-l  line  went  to  the  Multi-Unit  Tactical  Training  System  (MUTTS)  tower  at  Mayport, 
Florida.  Pierside  connection  to  Hue  City  was  through  a  wireless  LAN.  This  effectively  constituted  a 
separate,  secure,  tail  circuit  from  the  DSI  network. 
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3.4.3.4  Technical.  BFTT  is  a  closed-loop,  interactive  simulation,  tactical  combat  training  system. 
It  provides  scenario  generation  and  control,  simulation  of  friendly  and  enemy  forces,  and  stimulation 
of  organic  shipboard  sensors,  data  acquisition,  reconstruction,  and  operator  performance  feedback,  as 
well  as  connectivity  with  external  scenario  control  and  communication  with  remote  sites  through 
MUTTS.  MUTTS  integrates  tactical  communications  capability  (eight  live  voice  circuits),  a  Link  1 1 
circuit  (not  used  for  STOW-E),  and  a  data  line  for  network  traffic  with  500-KB  bandwidth.  Standard 
Navy  TAC-III  consoles  onboard  Hue  City  were  used  to  display  all  tracks.  Exercise  Control  and  tacti¬ 
cal  voice  communications  with  other  STOW-E  sites  were  maintained  over  six  cellular  telephones 
connected  through  Defense  Switched  Network  (DSN)  and  Federal  Telephone  System  (FTS). 

3.4.3.5  Results.  Significant  interface  problems  with  Hue  City  during  the  first  2  days  of  STOW-E 
severely  hampered  examining  a  complete  DIS  environment  at  the  Battle  Group  Commander  level. 
Incoming  DIS  simulation  data  was  not  consistent,  producing  intermittent  tracks.  Software  quick  fixes 
employed  during  STOW-E  improved  data  consistency,  but  did  not  totally  resolve  the  problem.  The 
BFTT  Program  Office  is  investigating  the  source  of  the  problem  to  determine  a  solution.  A  network 
limitation  of  300-KB  bandwidth  was  experienced  at  FCTCLANT.  BFTT  performance  began  to 
degrade  when  it  handled  more  than  100  entities.  Significant  benefits  from  participation  included  the 
revelation  of  some  BFTT  shortcomings,  both  design  and  performance,  that  will  help  the  BFTT  Pro¬ 
gram  Office  to  make  corrections  and  enhance  flexibility.  The  BFTT  Program  Manager  estimates  an 
18-month  savings  in  development  time  as  a  result  of  exposing  the  BFTT  prototype  to  joint  simula¬ 
tion  in  its  early  stages.  The  Navy’s  primary  objective  of  demonstrating  the  potential  to  train  person¬ 
nel  at  all  levels,  from  individual  tactical  console  operators  up  through  the  Battle  Group  Commander, 
in  a  DIS  environment,  was  met. 

3.5  TERRAIN  DATABASE 

3.5.1  Background 

Since  1990,  the  U.S.  Army  Topographic  Engineering  Center  (TEC)  has  developed  more  than  10 
tailored  terrain  databases  for  simulation  networking  in  support  of  ARPA  and  various  Army  custom¬ 
ers.  This  section  describes  the  family  of  terrain  database  products  developed  to  support  the  heteroge¬ 
neous  DIS  system  that  link  live,  virtual,  and  constructive  simulations  in  STOW-E. 

3.5.2  Objectives 

The  objectives  of  the  ARPA  Synthetics  Environments  Program  include  development  of  advanced 
technology  to  represent  and  generate  digital  terrain  databases  (TDBs)  to  support  increasingly  large 
and  complex  STOW  exercises. 

3.5.3  Approach 

Mapping,  reconnaissance,  and  Earth  resources  imagery  are  used  to  assess,  update,  and  enhance 
standard  digital  map  data  from  the  Defense  Mapping  Agency  (DMA)  to  generate  and  maintain  a  dig¬ 
ital  model  of  the  geographic  area  of  interest.  Simulation-specific  software  modules  are  developed  to 
transform  the  common  digital  geographic  model  into  a  set  of  tailored  real-time  TDBs  and  associated 
map  products. 

3.5.4  Synthetic  Environment  (SE)  Products 

The  STOW-E  synthetic  environments  consist  of  a  family  of  interoperable,  TDB  products  that  sup¬ 
port  distributed  ground,  air,  and  naval  simulations  linked  via  DIS  protocols  on  the  DSI. 


32 


3.5.4.1  Ground  Operations  TDB.  The  Ground  Operations  TDB  is  the  highest  resolution  TDB 
containing  transportation,  vegetation,  drainage,  soils,  building,  and  other  key  complex  features  of  the 
terrain  surface.  The  database  was  generated  from  1  arc-second  (approximately  30  meters)  DMA 
Digital  Terrain  Elevation  Data  (DTED)  and  DMA  Interim  Terrain  Data  (ITD)  (derived  from  the 
1:50,000  scale  operational  terrain  analysis  overlays).  Imagery,  map,  and  field  data  were  used  to  pop¬ 
ulate  additional  natural  and  cultural  features.  The  Ground  Operations  TDB  covers  a  geographic  area 
64  km  by  84  km  that  includes  Grafenwoehr  and  Hohenfels,  Germany.  The  data  was  furnished  to 
STOW-E  participants  in  a  variety  of  formats:  SIMNET  visual,  PVD,  SAF,  and  Management  Com¬ 
mand  and  Control  (MCC)  console  formats;  “Flight”  format  for  visual  simulation;  and  rasterized  fea¬ 
ture  files  for  the  BBS.  In  addition,  Simulation  Maps  (SIMMaps)  of  the  STOW-E  ground  operations 
area  were  produced  in  the  style  of  DMA  Topographical  Line  Maps  based  on  the  contents  of  simula¬ 
tion  TDB. 

3.5.4.2  Air  Operations  TDB.  The  Air  Operations  TDB  covers  a  geographic  area  of  232  km  by 
232  km  in  northern  Bavaria  that  includes  the  Ground  Operations  TDB  area.  This  is  a  multiresolution 
database  with  high-resolution  features  replicated  from  the  Ground  Operations  TDB  and  a  lower  reso¬ 
lution  textured  terrain  surface  outside  the  ground  operations  area.  The  database  was  generated  pri¬ 
marily  from  3  arc-second  (approximately  100  meters)  DTED  thinned  to  a  500-meter  grid.  Natural 
and  cultural  features  were  derived  from  the  ground  operations  database.  The  data  was  delivered  in  a 
variety  of  formats  including  versions  compiled  for  SIMNET  visual  simulators,  PVD,  SAF,  “Flight,” 
and  Loral  Advanced  Distributed  Simulation  (LADS)  “Vistaworks.”  Additional  standard  data  sources 
(e.g..  Digital  Feature  Analysis  Data  (DFAD))  were  provided  to  STOW-E  participants  to  support 
construction  of  tailored  flight  databases. 

3.5.4.3  Naval  Operations  TDB.  The  Naval  Operations  TDB  covers  a  geographical  area  244  km 
by  244  km  centered  in  the  northern  Mediterranean  Sea.  The  database  was  generated  from  3  arc- 
second  (approximately  100  meters)  DTED  thinned  to  a  500-meter  grid.  Coastline  features  were 
extracted  and  thinned  from  the  DMA  Digital  Chart  of  the  World.  The  data  was  delivered  in  a  variety 
of  formats  including  versions  compiled  for  SIMNET  visual  simulators,  PVD,  SAF,  “Flight,”  and 
LADS  “Vistaworks.”  Other  standard  data  sources  (e.g.,  DFAD)  were  provided  to  STOW-E  partici¬ 
pants  to  support  construction  of  additional  databases. 

3.5.5  TDB  Generation  Process 

The  TDB  generation  process  consists  of  several  phases:  design,  source  collection,  data  pre¬ 
processing  and  setup,  terrain  surface  generation,  editing,  preliminary  testing,  SIMMaps  production, 
compilation,  testing,  and  distribution. 

3.5.5.1  Design.  The  database  design  process  starts  with  the  gathering  of  user  requirements  for  data 
content,  schedule,  and  deliverables.  The  STOW-E  areas  of  operation  were  plotted  on  maps  to  iden¬ 
tify  required  sources  and  to  estimate  design  parameters  for  the  project.  Preliminary  decisions  were 
made  based  on  expected  data  sources  and  available  equipment  and  software  tools.  A  novel  approach 
to  generating  Triangular  Irregular  Network  (TIN)  was  selected  to  provide  enhanced  fidelity  to  the 
terrain  surface.  The  project  schedule  provided  for  incremental  deliveries  required  for  STOW-E 
Functional  Validation  tests. 

3.5.5.2  Source  Data  Collection.  Maps  and  digital  terrain  data  of  the  STOW-E  area  were  gathered 
and  evaluated.  Sources  that  met  the  fidelity  requirements  of  the  project  were  selected  for  use  in 
database  construction.  Data  modeling  personnel  traveled  to  the  STOW-E  area  to  collect  ground 
photographs  and  videotape  to  improve  understanding  of  the  terrain  and  to  support  subsequent  data¬ 
base  validation. 
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3. 5.5.3  Data  Pre-Processing  and  Database  Setup.  Digital  data  sources  in  ITD  Standard  Linear 
Format  (SLF)  were  read  and  thinned  using  a  commercial  Geographic  Information  System  (GIS). 
Thinning  reduced  the  volume  of  data  to  the  level  acceptable  for  distributed  simulation.  Data  attrib¬ 
utes  were  mapped  from  the  detailed  DMA  source  codes  to  the  limited  attribution  required  for  the 
simulation  systems.  Files  that  identify  the  project  area  were  initialized  and  site-specific  models  were 
defined. 

3.5.5.4  Terrain  Surface  Generation.  The  integrated  Triangular  Irregular  Networks  (iTIN) 
method  developed  by  the  Carnegie-Mellon  University  was  used  to  generate  the  terrain  surface  for 
the  Ground  Operations  TDB.  This  automated  method  iteratively  builds  a  surface  consisting  of  poly¬ 
gons  (mostly  triangles)  that  take  into  consideration  the  location  of  significant  terrain  features  (e.g., 
transportation  and  drainage).  The  method  also  controls  the  allowable  number  of  polygons  to  meet 
the  constraints  of  the  target  simulators. 

3.5.5.5  Database  Editing.  SIMNET  SI 000  database  modeling  tools  were  used  in  the  TDB  gen¬ 
eration  phase.  The  terrain  surface  was  edited  to  correct  key  terrain  features  that  were  distorted  by  the 
automated  iTIN  process.  The  transportation  and  drainage  network  was  adjusted  to  be  consistent  with 
the  terrain  surface.  Features  extracted  from  stereo  imagery  with  the  Digital  Photogrammetric 
Workstation  were  used  to  augment  the  database  as  needed.  In  addition,  feature  models  (e.g.,  build¬ 
ings)  were  placed  in  their  proper  location;  vegetation  features  were  added;  and  soil  types  were  speci¬ 
fied. 

3.5.5.6  TDB  Preliminary  Testing.  Preliminary  testing  was  conducted  as  part  of  the  TDB  genera¬ 
tion  process.  The  database  was  compiled  into  a  run-time  format  for  the  visual  simulators  available  at 
TEC.  Error  detection  tools  of  the  TDB  generation  software  were  used  to  identify  problem  locations. 
In  addition,  the  tester  flew  over  the  TDB  inspecting  the  database  visually  logging  discrepancies  with 
known  information  (e.g.,  imagery,  maps,  field  data).  Reported  errors  were  analyzed  and  corrected. 
The  process  was  iterated  until  no  more  errors  were  reported  by  the  software  tools  or  observed  by  the 
tester  and  the  database  was  considered  “frozen.” 

3.5.5.7  SIM  Maps  Production.  Twelve  1 :50,000  scale  SIMMaps  were  produced  for  the  ground 
operations  area.  The  terrain  and  feature  data  from  the  “frozen”  database  were  imported  into  a  com¬ 
mercial  GIS  where  automated  cartographic  tools  were  used  to  symbolize  all  the  map  features.  The 
SIMMaps  were  designed  to  emulate  DMA  Topographic  Line  Maps.  After  examination  of  color 
proof  plots  by  cartographers,  film  color  separates  were  generated  with  a  large  format  printer  and 
paper  maps  were  generated  in  volume  by  lithographic  press. 

3.5.5.8  Brigade/Battalion  Battle  Simulation  (BBS).  Terrain  features  required  for  BBS  TDB 

generation  were  extracted  from  the  “frozen”  database  through  GIS  vector-to-raster  operations  and 
furnished  to  the  National  Simulation  Center  (NSC)  for  incorporation  into  the  real-time  BBS  TDB. 

3.5.5.9  Database  Compilation.  Automated  TDB  compilers  were  used  to  generate  the  various  for¬ 
mats  required  by  STOW-E  simulation  systems.  Each  of  the  compilation  activities  resulted  in  a  data¬ 
base  in  one  of  the  following  formats:  SIMNET  or  Flight  visual  simulation,  SAF,  PVD,  MCC,  or 
BBS  raster  files. 

3.5.5.10  Testing.  Final  product  testing  occurred  after  compilation  by  loading  the  visual  and  SAF 
databases  on  the  appropriate  systems  at  TEC  and  at  the  Institute  for  Defense  Analysis  (IDA).  Visual 
databases  were  tested  primarily  by  “flying”  over  the  database  extent.  For  SAF  databases,  vehicle 
behavior  was  checked  against  known  behavior.  Anomalies  observed  in  this  phase  of  testing  were 
addressed  by  corrections  to  the  TDB  source  and  recompilation. 
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3.5.5.11  Distribution.  The  STOW-E  TDBs  were  installed  on  a  file  server  at  IDA  for  distribution  to 
STOW-E  participants  via  Internet.  The  TDBs  were  also  shipped  to  selected  participants  in  request 
magnetic  media  formats.  Sheets  of  paper  SIMMaps  were  sent  to  all  STOW-E  participants. 

3.5.6  Technology  and  Tools  for  TDB  Construction 

A  variety  of  general  purpose  and  specialized  tools  were  used  to  generate  the  STOW-E  TDBs.  The 
SI 000  modeling  and  TDB  construction  tools  that  were  developed  to  support  the  ARPA  SIMNET 
Program  continue  to  evolve;  for  example,  a  new  S1000  Application  Programmer’s  Interface  facili¬ 
tates  direct  access  to  the  source  data.  The  Arc/Info  GIS  was  used  throughout  the  TDB  generation 
process  to  input,  process,  edit,  and  perform  cartographic  symbolization.  Features  in  the  standard 
data  sources  (ITS)  were  assessed  and  augmented  with  a  variety  of  stereo  imagery  using  the  Digital 
Photogrammetric  Workstation.  Automated  generation  of  iTIN  surfaces  for  distributed  simulation 
represents  on-going  research  at  the  Digital  Mapping  Laboratory,  Carnegie-Mellon  University,  under 
the  joint  sponsorship  of  ARPA  and  TEC.  The  STOW-E  ground  operations  TDB  represents  the  first 
time  that  this  technology  has  been  applied  to  a  project  of  this  extent  and  complexity. 

3.6  MODULAR  SEMI-AUTOMATED  FORCES 

The  What  If  Simulation  System  for  Advanced  Research  and  Development  (WISSARD)  is  located 
at  the  Naval  Air  Station  Oceana,  Virginia  Beach,  Virginia.  This  section  focuses  on  how  WISSARD 
employed  Modular  Semi-Automated  Forces  (ModSAF)  in  support  of  STOW-E,  WISSARD  STOW-E 
operations  in  general,  and  some  high-level  discussion  of  ModSAF  operation.  WISSARD  provided 
not  only  ModSAF  to  the  STOW-E  demonstration  but  also  Intelligent  Forces  (IFOR),  F-14  simula¬ 
tors,  and  an  F-18  simulator.  Section  3.7  of  this  document  describes  IFOR  and  its  participation  in 
STOW-E.  There  are  references  to  IFOR  in  this  section  but  it  is  from  an  operational  viewpoint. 

There  is  a  brief  description  of  the  F-14  and  F-18  simulator  participation  as  well.  Note  that  all 
STOW-E  scenario  events  are  referenced  from  the  Navy  tactical  scenario  developed  specifically  for 
the  STOW-E  demonstration  by  members  of  the  staff  of  Commander,  Tactical  Training  Group  Atlan¬ 
tic. 

3.6.1  WISSARD  Computer-Generated  Forces  Workstation  Configuration 

WISSARD  output  computer-generated  forces  (ModSAF  and  IFOR)  from  a  total  of  six  SGI 
workstations.  Four  workstations  were  dedicated  for  ModSAF  generation.  Two  workstations  were 
dedicated  for  IFOR  generation.  A  seventh  workstation  was  used  as  a  “pocket”  SAF  system.  This 
workstation  was  used  by  “Navy”  (the  U.S.  Navy  exercise  liaison  officer)  as  a  Battlemaster-like  sta¬ 
tion  for  observation,  not  to  generate  entities.  WISSARD  used  ModSAF  Version  1.3  and  STOW-E 
TDB  -0104  for  its  ModSAF  workstations. 

WISSARD  generated  ModSAF  aircraft  from  four  workstations.  One  workstation,  an  SGI  Iris 
Indigo  (R4000)  provided  BLUFOR  and  was  set  up  to  function  as  a  SAF  Station.  This  workstation 
was  paired  up  with  an  SGI  Indigo  Extreme  (R4400)  that  functioned  as  a  SAF  Simulator  (SAF  Sim) 
for  the  machine.  Another  SGI  Iris  Indigo  (R4000)  was  used  to  provide  Opposition  Forces  (OPFOR) 
and  was  set  up  to  function  as  a  SAF  Station.  This  R4000  was  paired  with  another  R4000  that  func¬ 
tioned  as  a  SAF  Sim  for  the  OPFOR  machine.  Experience  in  generating  vehicles  during  the  period 
leading  up  to  STOW-E  led  to  the  decision  to  pair  up  discrete  machines  for  use  as  SAF  Stations  and 
SAF  Sims. 

WISSARD  generated  IFOR  from  two  workstations.  An  SGI  Indy  (R4400)  was  used  to  generate 
IFOR  vehicles  in  conjunction  with  another  SGI  Indigo  Extreme  (R4400). 
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One  SGI  Indigo  Extreme  (R4400)  was  used  as  a  “pocket”  SAF  for  the  person  manning  the  WIS- 
SARD  Exercise  Coordinator  station.  This  machine  was  not  used  to  generate  any  entities  during  the 
4-day  STOW-E  demonstration  period  but  was  used  for  observation. 

3.6.2  Persistent  Object  Protocol  Database  ID  Numbers 

For  STOW-E,  WISSARD  paired  workstations  to  function  as  SAF  Stations  and  SAF  Sims  through 
the  use  of  discrete  Persistent  Object  Protocol  (POP)  database  ID  numbers.  Additionally,  any  other 
ModSAF  workstation  on  the  WISSARD  LAN  was  given  its  own  discrete  POP  database  ID  number 
to  preclude  unwanted  intrusion  from  ModSAF  systems  at  other  sites. 

The  implementation  of  discrete  POP  database  numbers  and  SAF  Station  and  SAF  Sim  pairings 
gave  WISSARD  two  major  options:  (1)  For  example,  if  one  pairing  of  machines  for  OPFOR  had  a 
problem  necessitating  a  reboot,  it  would  only  affect  the  operations  from  that  set  of  machines,  not  the 
operation  of  entities  from  another  pairing  of  machines  supporting  BLUFOR.  (2)  Management  of 
workstations  in  this  fashion  allowed  management  of  the  ModSAF  loading.  Knowing  the  load  the 
workstations  could  handle  before  crashing,  WISSARD  could  “flow”  the  entities  throughout  the  sce¬ 
nario  in  an  orderly  fashion.  If  machines  from  other  sites  were  to  use  WISSARD  workstation  excess 
capacity,  it  would  become  difficult  to  manage  the  creation  of  new  entities  when  dictated  by  the  sce¬ 
nario.  Discrete  POP  database  ID  numbers  made  WISSARD  ModSAF  network  operations  more 
manageable  and  predictable. 

3.6.3  Scheduled  WISSARD  ModSAF  and  IFOR  Entities  for  STOW-E 

ModSAF  and  IFOR  Force  Mix  entities  included  the  following  types:  F/A-18,  F-14,  MiG-29,  KS-3 
(vehicle  approximated  by  an  A- 10),  and  AWACS.  WISSARD  attempted  to  remain  within  the  bounds 
of  the  preplanned  entity  count  due  to  sizing  of  the  Application  Gateway  and  network  load  planning. 
Deviations  from  the  plan  were  made  with  the  approval  of  the  STOW-E  Navy  representative  located 
on-site  at  WISSARD.  The  maximum  number  of  computer-generated  vehicles  was  achieved  on  6 
November: 

Day  3,  time  0+00  to  2+00:  29  ModSAF/0  IFOR 

Day  3,  time  2+00  to  4+00:  19  ModSAF/7  IFOR  (IFOR:  MiG-29) 

Day  3,  time  4+00  to  6+00:  25  ModSAF/2  IFOR  (IFOR:  MiG-29) 

Day  3  Totals:  73  ModSAF/9  IFOR  for  82  computer-generated  vehicles 

3.6.3.1  Additional  WISSAR D-Generated  Entities  for  STOW-E.  The  following  three  simulators 
were  planned  to  participate  in  STOW-E: 

a.  WISSARD  F-14  Simulators:  These  are  Navy  Training  Device  2E6,  F-14A  Air  Combat 
Maneuvering  (ACM)  Trainers.  Composed  of  two  trainers,  each  is  a  40-foot  dome  procedural 
trainer  used  to  teach  the  basics  of  air-combat-maneuvering.  They  can  operate  in  either  the 
integrated  mode  where  both  trainers  are  brought  up  together  and  work  in  unison  or  the  inde¬ 
pendent  mode  where  each  dome  trainer  operates  independent  of  the  other  with  no  merging  of 
operations. 

b.  WISSARD  F/A-18  Simulator:  This  is  a  workstation-based  F/A-18  Hands  on  Throttle  and 
Stick  (HOTAS)  simulator  optimized  for  beyond-visual-range  air-to-air  engagements.  This 
Basic  Air  Tactics  Trainer  (BATT)  is  a  VAX-based  rack  mount  arrangement  of  cathode-ray 
tubes  (CRTs)  coupled  with  a  shelf  holding  replicas  of  the  F/A-18  throttle  and  stick.  CRT 
graphics  are  driven  by  two  SGI  4D/310VGXT  computers.  The  BATT  was  configured  with 
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two  touch-sensitive  CRTs.  The  upper  CRT  displayed  an  out-the-window  view  with  the  HUD 
image  superimposed.  The  lower  CRT  displayed  three  multi-function  displays  and  various 
other  essential-to-flight  indicators.  The  BATT  operates  on  an  NAS  Fallon,  NV,  terrain  data¬ 
base.  Through  the  use  of  coordinate  transformation,  it  participated  in  the  STOW-E  theater  of 
operations. 

c.  Fixed  Wing  Air-to-Ground  Simulator:  WISSARD  had  planned  to  have  two  air-to-ground  sim¬ 
ulators.  Due  to  technical  problems  integrating  them  onto  the  DIS  network  and  a  very  late  start, 
they  were  not  used  for  STOW-E.  They  were  to  have  flown  during  one  event  per  day  for  a 
strike  into  the  TDB. 

3.6.4  Highlights  of  WISSARD  Manned  Simulator  Operation  for  STOW-E 

The  following  are  accomplishments  during  STOW-E: 

a.  First  formation  flight  with  actual  aircraft,  manned  simulators,  and  computer-generated  forces. 

b.  Communication  link  with  “Hawkeye”  Cherry  Point  TACTS  Range  Control  and  with  live  air¬ 
craft. 

c.  Formation  flight/coordinated  strike  with  F-16  trainer  (Falcon  Star)  in  Grafenwoehr,  Germany, 
with  air  control  provided  by  the  TACCSF  AWACS.  The  visual  displays  in  the  domes  were  as 
solid  as  for  ModSAF/IFOR  workstation  displays,  and  formation  flight  was  maintained  for  the 
160-nm  strike  route. 

d.  Formation  flight/coordinated  strike  (300-nm  route)  with  the  Pax  River  F-l  8  manned  simulator, 
the  WISSARD  F-l 8  BATT,  the  TACCSF  computer-generated  F-l 5s,  and  all  under  TACCSF 
AWACS  control. 

e.  Formation  flight  on  Armstrong  Lab’s  F-16  simulators  over  the  TDB. 

3.6.5  Lessons  Learned,  Comments,  and  Recommendations 

Given  the  stage  of  the  development  of  the  air  model  for  ModSAF  and  the  relative  lack  of  attention 
it  has  received  over  years  of  ground  maneuver  SIMNET  SAFOR  and  ground  maneuver  ModSAF 
development,  ModSAF  Air  effectively  provides  the  combat  domain  with  a  large  number  of  air  enti¬ 
ties  possessing  basic  offensive  and  defensive  capabilities.  ModSAF  Air  proved  to  be  good  for  basic 
targeting  and  to  elicit  initial  behaviors  from  flight  crews.  It  is  recommended  that  work  continue  on 
the  ModSAF  Air  vehicles  to  mature  their  characteristics,  capabilities,  and  behaviors  and  on  the  Mod¬ 
SAF  user  interface  to  improve  the  ease  of  the  human  console  operator’s  interaction  with  the  Mod¬ 
SAF  and  to  allow  the  human  operator  to  get  the  most  out  of  the  ModSAF  station. 

A  lesson  learned  during  STOW-E  in  the  use  of  ModSAF’s  POP  led  WISSARD  to  ensure  that  its 
ModSAF  workstations  used  discrete  POP  database  numbers.  It  was  discovered  that  any  machine 
generating  ModSAF  on  the  entire  DSI  network  would  attempt  to  take  advantage  of  unused  processor 
operations  of  any  other  ModSAF  workstation  on  the  network  using  the  same  POP  ID.  Specifically, 
IDA  was  generating  ModSAF  entities  by  using  unused  processor  operations  from  a  WISSARD 
machine  on  the  same  (default)  POP  database  ID. 

The  2E6  is  a  classic  case  of  using  a  “Legacy”  training  system  in  a  DIS  environment.  As  a  result, 
the  use  of  the  2E6  in  the  STOW-E  scenario  attempted  to  optimize  its  capabilities  and  not  put  it  in  sit¬ 
uations  where  it  would  be  at  a  disadvantage  due  to  equipment  limitations.  For  example,  the  2E6  only 
“sees”  (radar  and  visually)  four  targets  in  the  integrated  mode  and  two  targets  in  the  independent 
mode.  It  chooses  the  closest  four  targets.  These  limitations  make  missions  involving  strike  escort 
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difficult  since  the  strike  aircraft  take  up  the  four  slots  and  don’t  drop  out  until  bogey  aircraft  get 
closer  to  the  2E6  than  the  strike  package.  That  makes  for  extremely  short  opportunity  ranges  and 
negates  the  advantage  of  the  long-range  missiles,  and  in  some  cases,  even  the  medium-range  mis¬ 
siles.  The  bogeys  obviously  are  not  constrained  to  seeing  the  closest  four  targets.  This  problem  will 
likely  not  go  away  without  significant  upgrades  to  the  simulators. 

WISSARD  ran  phone  lines  into  the  domes  to  permit  the  controlling  agency  to  talk  directly  to  the 
aircrew.  However,  there  was  so  much  noise  in  the  domes  that  it  was  extremely  difficult  to  hear  any 
of  the  communications.  The  solution  was  to  only  have  the  radar  intercept  officer  on  the  phone  net. 
He  then  passed  the  information  (via  ICS)  to  the  pilot  and  built  the  situation  awareness  for  the  section. 

Equipment  was  procured  for  the  express  purpose  of  integrating  the  phone  system  directly  into  the 
cockpit  headset  (normal  UHF  comm)  system.  This  equipment  was  not  used  due  to  a  number  of  fac¬ 
tors  such  as:  (1)  negative  comments  from  TACCSF  on  its  experience  trying  to  do  the  same  thing; 

(2)  it  appeared  to  be  an  invasive,  time-risk  procedure  that  WISSARD  personnel  were  not  comfort¬ 
able  tackling,  given  the  pace  of  pre-STOW-E  testing;  and  (3)  the  2E6  Contractor  Operation  and 
Maintenance  Systems  contract  had  just  been  let  and  their  personnel  were  just  getting  up  to  speed  and 
were  not  available  to  help  in  the  implementation.  The  communication  issue  should  be  resolved  for 
follow-on  Advanced  Concepts  Technical  Demonstrations  (ACTDs)  to  keep  it  from  being  such  a 
detractor  from  the  aircrew  perspective. 

There  were  good  comments  from  all  crews:  This  training  capability  represents  a  quantum  leap 
above  what  exists  in  the  2E6  as  a  stand-alone  trainer.  The  ability  to  operate  in  mixed  section  as  well 
as  mixed  divisions  versus  human-in-the-loop  threats  and  automated  (IFOR)  threats  is  unparalleled. 
The  ability  to  fly  formation  on  live,  virtual,  and  Computer-Generated  Forces  (CGFs)  seamlessly  was 
demonstrated  on  numerous  occasions — a  real  attention  getter  for  all  participating  aircrews.  On 
numerous  occasions,  the  2E6  was  able  to  fly  with  and/or  against  the  F-16  Falcon  Star  from  Germany, 
the  F-16s  out  of  Armstrong  Lab,  the  F-18  Manned  Flight  Simulator  (MFS)  from  Patuxent  River,  and 
the  F-15  from  Kirtland  AFB. 

The  communication  problems  experienced  in  the  2E6  remain  for  the  BATTs  but  to  a  lesser  extent. 
The  noise  problem  encountered  by  the  BATTs  was  more  a  result  of  conversations  by  people  in  the 
room  (the  BATT  is  located  in  the  main  WISSARD  lab  room)  overpowering  the  volume  level  of  the 
phone  patch.  WISSARD  needs  to  find  a  way  to  either  boost  the  phone  signal  (WISSARD  already 
tried  in-line  amplifiers)  or  run  the  signal  through  the  BATT  voice  hardware  that  is  used  to  talk 
between  the  2E6  and  the  BATTs  in  the  integrated  mode. 

Currently,  the  BATT  can  only  see  (radar  and  visually)  the  closest  six  air  entities.  This  is  not  as 
limited  as  the  2E6.  The  BATT’s  original  developer  has  indicated  that  display  of  entities  in  excess  of 
15  is  possible.  The  current  limitations  regarding  the  TDB  (currently  only  NAS  Fallon  and  China 
Lake),  and  the  entities  (currently  only  six)  can  be  corrected.  A  key  consideration  is  the  cost  versus 
the  value  added. 

3,7  INTELLIGENT  FORCES 
3.7.1  Introduction 

IFORs  stands  for  automated  Intelligent  FORces.  Ideally,  IFORs  allow  replacement  of  human  con¬ 
trol  of  selected  units  on  the  simulated  battlefield  by  automated  control  without  noticeably  degrading 
the  appropriateness  of  the  resulting  behavior.  In  practice,  this  ideal  can  be  quite  difficult  to  achieve. 
However,  experience  with  the  current  fielded  state  of  the  art  in  this  area  (the  semi-automated  forces 
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[SAFORs]  in  SIMNET  and  its  immediate  successors)  suggests  that  even  very  approximate  IFORs 
can  improve  the  realism  of  simulated  engagements.  The  principal  reason  is  that,  when  there  are  not 
enough  humans  (and  associated  simulators)  available  to  fully  populate  the  battlefield,  populating  it 
with  even  “dumb”  IFORs  yields  more  realism  than  would  leaving  it  inappropriately  unpopulated. 
The  WISSARD  facility  provided  not  only  ModSAF  to  the  STOW-E  demonstration/exercise  but  also 
IFORs. 

3.7.2  Goals 

The  following  were  IFOR  goals  for  participation  in  STOW-E: 

a.  Participate  in  a  large-scale  operational  exercise.  The  goal  here  was  to  test  whether  the  soft¬ 
ware  was  sufficiently  mature  to  work  in  such  a  large  exercise  over  an  extended  period  of  time. 

b.  Learn  what  is  required  for  theater-level  exercises.  Earlier  work  had  been  in  very  limited  sce¬ 
narios  with  very  little  exposure  to  how  the  work  fits  into  a  complete  theater-level  exercise. 

c.  Provide  viable  IFOR  opponents  for  human  and  ModSAF  forces. 

d.  (Knowledge  Acquisition).  Learn  about  what  is  required  for  more  advanced  IFOR  opponents 
in  air-to-air  and  air-to-ground  combat. 

3.7.3  Results 

3.7.3.1  Participation.  IFOR  vehicles  were  successfully  fielded  for  every  scheduled  event  (10 
events,  approximately  32  vehicles)  and  in  many  unscheduled  events  (5  to  7  events,  approximately  16 
vehicles).  Air-to-air  missions  were  performed  against  ModSAF  and  humans  in  the  BATTs  and  the 
2E6.  The  attempt  was  made  to  engage  planes  from  other  sites,  but  they  never  reacted  to  the  IFOR 
planes  and  would  typically  fall  off  the  net  before  the  IFOR  planes  could  get  off  missile  shots.  The 
IFOR  planes  did,  however,  participate  in  air-to-ground  (bombing  bridges,  etc.)  and  air-to-surface  (fir¬ 
ing  missiles  at  ships)  attacks  in  which  there  were  successful  engagements  with  ground  and  surface 
targets  from  other  sites. 

There  were  a  limited  number  of  software  failures  with  the  most  significant  being  the  inability  to 
fly  over  the  TDB  where  the  ground  battle  was  raging  when  it  was  populated  with  hundreds  of  tanks. 
There  was  no  problem  flying  over  the  TDB  when  it  was  not  populated  with  tanks — this  was  tested 
when  Europe  was  off-line. 

Possibly  the  best  example  of  successful  IFOR  participation  was  in  the  execution  of  an  unscheduled 
event  for  the  second  day.  In  this  mission,  a  section  of  FI 8s  were  to  perform  a  ground  attack  against 
the  Star  Islands.  IFOR  planes  were  used  in  place  of  a  virtual  (manned)  ground  attack  because  of  the 
failure  of  the  simulator.  Enroute  to  the  target,  the  planes  were  unexpectedly  intercepted  by  ModSAF 
MiG-29s.  The  FI 8s  engaged  the  MiG-29s  to  defend  themselves  and  got  off  one  or  two  shots  (but  no 
kills).  The  MiG-29s  either  disappeared  (fell  off  the  net)  or  disengaged,  and  the  F18s  reinitiated  their 
air-to-ground  attack.  Further  enroute,  they  were  unexpectedly  fired  on  from  a  surface-to-air  site, 
killing  the  wingman.  This  was  an  unscripted  iteration  since  no  surface-to-air  systems  were  scheduled 
to  participate  in  STOW-E.  The  lead  continued  on,  successfully  dropping  bombs  on  the  designated 
target  and  then  egressing  back  to  base. 

3.7.3.2  Learn  About  Theater-Level  Exercises.  STOW-E  was  an  excellent  educational  experi¬ 
ence  in  terms  of  what  is  required  of  IFOR  vehicles  for  these  large-scale  exercises.  IFOR  vehicles 
need  to  be  more  flexible  in  performing  their  missions.  The  IFORs  required  more  effort  to  set  up  for 
a  mission  than  the  ModSAF  vehicles,  and  there  was  less  flexibility  in  retasking  them  during  a 
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mission;  however,  they  did  run  completely  autonomously  during  their  missions,  and  didn’t  require 
continued  monitoring  as  did  ModSAF.  Mission  entries  need  to  be  made  as  easy  or  easier  than  Mod- 
SAF,  and  retasking  the  IFORs  should  be  made  easier  if  a  mission  needs  to  be  changed. 

3.7.3.3  Provide  Viable  IFOR  Opponents  for  Human  and  ModSAF  Forces.  Overall,  viable 
IFOR  opponents  were  provided.  However,  it  was  difficult  to  evaluate  the  “skill”  of  IFOR  planes 
due  to  problems  with  the  underlying  simulation  models.  Day  1  performance  of  IFOR  planes  in 
engagements  was  frustrating.  The  planes  were  easily  shot  down  by  ModSAF  F/A-18s.  It  was  dis¬ 
covered  that  the  ModSAF  F/A-l  8s  were  carrying  Phoenix’s,  which  would  be  contrary  to  real  life.  In 
engagements  with  humans,  the  IFOR  vehicles  would  often  get  into  good  tactical  positions  only  to  see 
the  missiles  miss  when  they  were  shot.  There  were  some  kills  against  both  the  BATT  and  2E6s,  but 
in  general,  the  IFOR  vehicles  got  “toasted.”  The  primary  cause  of  the  misses  is  suspected  to  be  due 
to  fundamental  flaws  in  the  ModSAF  missiles. 

3.7.3.4  Knowledge  Acquisition.  The  structure  of  STOW-E  made  it  impossible  to  do  controlled 
knowledge  acquisition,  but  the  interactions  that  did  arise  allowed  for  spontaneous  knowledge 
acquisition.  In  the  future,  it  is  clear  that  the  WISSARD  site  will  be  able  to  be  used  for  significant 
knowledge  acquisition  although  the  classification  of  the  2E6  domes  will  continue  to  be  a  hindrance. 

3.7.4  Summary  of  Primary  Problems  to  Address 

3.7.4.1  Overall  Computational  Requirements.  One  disappointment  was  in  the  number  of  IFOR 
vehicles  that  could  effectively  be  run  on  a  single  machine  during  these  engagements  (maximum  of 
four).  The  system  needs  to  be  reviewed  from  top  to  bottom  to  find  out  what  the  problems  were.  The 
processing  of  vehicles  that  are  not  directly  relevant  to  a  plane’s  mission  need  to  be  filtered  out  as 
early  as  possible.  This  may  require  modifications  to  ModSAF,  the  Soar  architecture,  and/or  the 
knowledge  encoded  in  the  Soar/IFOR  agents.  The  possibility  for  Soar/IFOR  agents  to  run  on  just  . 
SAF  Sim,  eliminating  the  overhead  of  the  graphical  user  interface,  will  be  looked  into.  Future  exer¬ 
cises  will  require  much  more  computational  power. 

3.7.4.2  Interfaces  for  Defining  and  Retasking  Missions.  The  construction  of  new  interfaces  is 
about  to  begin.  STOW-E  provided  useful  input  for  the  requirements  of  such  interfaces. 

3.7.4.3  Improvement  in  ModSAF  Missile  and  Airframe  Models.  ModSAF  missile  and  air¬ 
frame  models  need  to  be  improved. 

3.7.5  Goals  and  Plans  for  Future  Exercises 

This  was  an  extremely  useful  exercise.  However,  it  is  not  clear  that  a  repeat  of  this  type  of  exer¬ 
cise  in  6  months  would  be  of  much  value.  An  exercise  stressing  command  and  control  of  close-air 
support  missions  would  be  useful  in  6  months  to  a  year.  Also  in  a  year,  a  more  limited  exercise 
involving  rotary-wing  aircraft  anti-armor  would  be  useful.  Although  the  1500  ground  entities 
stressed  the  network  and  the  underlying  software,  smaller  exercises  (battalion  level)  that  involved  a. 
range  of  systems  (air,  ground,  air-to-air,  air-to-ground),  would  be  most  useful  over  the  next  year  with 
exercises  of  10K  entities  being  scheduled  for  18  months  or  so. 

3.7.6  Significance  of  IFOR  Participation 

This  exercise  has  the  additional  significance  of  demonstrating  that  “hardcore”  AI  technology  can 
be  successfully  used  in  an  operational  exercise.  This  is  one  of  the  first  (if  not  the  first)  time  that  an 
AI  system  has  been  used  in  this  way.  This  demonstrates  a  real  success  of  taking  technology  devel¬ 
oped  under  ARPA  research  programs  (6.1,  6.2)  and  having  an  impact  on  the  operational  side. 
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4.0  TECHNIQUES 


4.1  EXPERIMENTAL  PROTOCOL  DATA  UNITS 

4.1.1  Introduction 

In  the  development  of  STOW-E,  a  number  of  experimental  PDUs  were  developed  at  NRaD  and 
the  Naval  Underwater  Warfare  Center  (NUWC)  to  supplement  those  PDUs  defined  in  the  DIS  proto¬ 
col  standard.  The  200  series  PDUs  listed  below  (Application  Gateway-to-Gateway  Protocol)  were 
used  to  reduce  the  number  of  standard  PDUs  sent  on  the  DSI.  This  reduction  allowed  for  data  to  be 
exchanged  between  sites  within  an  effective  bandwidth  of  1.1  Mbps.  This  limitation  was  imposed  on 
STOW-E  by  hardware  components  of  the  DSI.  The  following  PDUs  were  sent  over  the  DSI  in  addi¬ 
tion  to  those  available  from  the  standard. 

4.1 .1.1  Experimental  PDUs  Developed  by  NRaD 

# 133  Aggregate  PDU  Kind 

This  PDU  provides  an  aggregate,  hierarchical  representation  of  DIS  entities.  It  provides  the  mech¬ 
anism  to  pass  aggregate  data  so  that  commanders  sitting  at  “2-D”  battle  monitoring  stations  can  see 
the  entire  battlefield,  and  so  that  AAR  systems  can  record  the  positional  data,  hierarchical  data,  and 
aggregate  combat  power  of  all  units  in  the  battle  for  later  playback  and  review. 

#750  Marker  PDU  Kind 

This  PDU  is  used  to  describe  the  parameters  necessary  for  using  Minefield  Markers.  The  informa¬ 
tion  includes  location,  orientation,  update  frequency,  and  type  of  marker  (mine,  breach,  etc.). 

#200  Subscriber 

This  PDU  is  sent  from  each  site  upon  startup  to  notify  other  sites  that  it  is  a  participant.  It  defines 
the  subscriber’s  address. 

#201  Master  Grid 

This  PDU  is  sent  from  the  “start  up”  site  to  define  the  playbox  latitude,  longitude,  altitude,  and 
grid  information  where  the  exercise  is  to  be  conducted. 

#202  Packet  Rate 

This  PDU  is  sent  when  there  is  a  change  in  bandwidth  percentage  for  Load  Leveling. 

#203  Control 

This  PDU  is  sent  when  there  is  a  change  in  the  enable/disable  status  of  Grid  Filtering,  Load  Level¬ 
ing,  Compression,  or  Bundling. 

# 204  Grid  Subscriber 

This  PDU  is  sent  to  notify  other  sites  when  there  is  a  change  in  grid  locations  of  interest  to  a  site.  It 
contains  the  address  of  the  sender,  the  destination,  and  the  number  and  the  location  of  changed  grids. 

#206  Compressed  Entity  State  (ES) 

This  PDU  is  sent  in  place  of  the  standard  Entity  State  PDU  when  Compression  is  enabled. 
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#207  Bundled 


This  PDU  is  sent  when  Bundling  is  enabled.  It  defines  the  number  of  PDUs  bundled  and  the  data 
in  the  bundle. 

# 208  Request  ES  PDU 

This  PDU  is  sent  if  a  Compressed  PDU  has  been  received,  but  a  full  PDU  has  not  been  stored,  and 
a  full  update  is  necessary. 

#210  Quiescent  Request 

This  PDU  is  sent  when  an  entity  deemed  quiescent  cannot  be  located  in  the  LAN  or  the  informa¬ 
tion  stored  for  that  entity  ID  does  not  indicate  a  quiescent  entity. 

#211  Quiescent  State  Change 

This  PDU  is  sent  periodically  or  when  there  is  a  change  in  a  Quiescent  Entity  List. 

#212  Quiescent  Full  List 

This  PDU  is  sent  periodically  to  establish  reliable  data  transfer. 

#213  Summary  ES  PDU 

This  PDU  is  sent  upon  receipt  of  a  Quiescent  Entity  PDU  (#210)  to  provide  the  most  current  data 
for  a  specific  entity. 

#214  Reliable 

This  PDU  is  sent  to  Acknowledge  receipt  of  a  specific  entity. 

#215  Delete 

This  PDU  is  sent  to  Not  Acknowledge  receipt  of  a  specific  entity. 

4.1.1 .2  Experimental  PDUs  developed  by  NUWC 

#171  Underwater  Acoustic 

This  PDU  is  sent  to  define  Active  Emissions  and  Passive  Signatures  of  specific  entities. 

#173  Transfer  Control  Request  (Hand  Off  Request) 

This  PDU  is  a  request  to  a  site  to  take  control  of  a  specific  entity. 

#174  Transfer  Control  (Hand  Off) 

This  PDU  is  sent  in  response  to  the  Transfer  Control  Request  (#173)  acknowledging  that  control 
of  a  specific  entity  has  been  taken  by  another  site. 

#175  Transfer  Control  Acknowledge  (Hand  Off  Acknowledge) 

This  PDU  is  sent  to  acknowledge  receipt  of  a  Transfer  Control  (#174)  PDU. 
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4.2  SECURITY 


4.2.1  Overall 

STOW-E  was  executed  as  a  multi-security-level  exercise.  Unclassified,  US1,  and  Secret 
NOFORN  simulation  sites  were  linked  together  over  the  DSI  during  STOW-E  via  one-way  data 
links.  Motorola’s  Improved  Performance  Network  Encryption  System  (INES)  was  used  to  provide 
National  Security  Agency  (NSA)  approved  encryption  at  the  Secret  level  between  classified  sites. 

4.2.2  DSI  Security 

All  data  from  Red  (classified)  STOW-E  sites  was  assumed  classified  at  the  Secret  level  unless  a 
memorandum  from  the  site  facility  manager  was  received  affirming  no  classified  data  was  entered 
into  the  network  from  that  site. 

The  Security  Guard  included  a  modification  to  existing  network  architecture  allowing  multi-level 
security.  An  Allied  Telesis  CentreCOM  fiber-optic  hub/repeater  (P/N  3606F-15)  and  an  Allied  Tele- 
sis  CentreCOM  fiber-optic  transceiver  (P/N  AT-MX26FL)  were  used  as  an  NSA-approved  data 
diode,  permitting  unclassified  data  to  be  bridged  into  classified  spaces  while  preventing  classified 
data  from  passing  out  to  unclassified  sites.  Thus,  classified  STOW-E  sites  were  able  to  view  and 
interact  with  entities  generated  at  unclassified  sites  in  a  limited  way.  Unclassified  sites  were  unable 
to  see  or  interact  with  any  entities  generated  by  classified  sites. 

INES  operations  were  managed  by  DSI  personnel.  This  included  configuration  disk  and  key  man¬ 
agement  as  well  as  coordination  of  daily  rekeying  times.  This  required  close  operational  coordina¬ 
tion  between  DSI  and  SEAF  Technical  Control.  DSI  operations  were  coordinated  and  controlled  via 
the  Network  Operations  Center  (NOC)  in  Ft.  Leavenworth,  Kansas,  and  the  alternate  (STOW-E) 
NOC  in  Alexandria,  Virginia. 

An  effort  was  made  to  proceed,  to  the  greatest  degree  possible,  within  a  paperless  environment,  in 
regard  to  security.  Although  some  security  documents  were  mandatory,  by  minimizing  the  amount 
of  paperwork  required  for  secure  STOW-E  operations,  the  entire  process  was  greatly  streamlined. 

Security  Memorandums  of  Agreement  (MOAs)  were  signed  between  each  DSI  site  and  DSI  man¬ 
agement  and  also  between  each  STOW-E  back-door  site,  its  DSI  front-end  node,  and  DSI  manage¬ 
ment.  Sites  originally  nominated  for  STOW-E  participation  went  through  a  maturation  process  with 
respect  to  the  following  aspects:  people,  procedures,  data,  hardware,  software.  Final  sites  were  those 
that  eliminated  all  risk  categories. 

4.2.3  Lessons  Learned 

One  of  the  security  lessons  learned  during  STOW-E  was  that  although  both  the  technical  and  sce¬ 
nario  conference  calls  were  unclassified,  no  concerted  effort  was  made  to  ensure  that  the  conversa¬ 
tions  held  over  these  lines  were,  in  fact,  unclassified.  Although  no  classified  conversations  were 
actually  conducted  over  the  nonsecure  conference  call  during  STOW-E,  this  remains  one  area  for 
improvement  during  future  exercises  using  clear  conference  calls  for  technical  and  force  coordina¬ 
tion.  Future  use  of  digitized  voice  over  the  secure  DSI  or  the  use  of  STU-III  telephones  may  allevi¬ 
ate  this  potential  security  risk. 
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4.2.4  STOW-E  Evaluation  and  Analysis  Facility  (SEAF) 

A  security  manager  was  assigned  the  following  responsibilities: 

a.  Provide  secure  mailing  support  for  classified  STOW-E  documents  and  data  logger  tapes. 

b.  Facilitate  badging,  escorts,  and  clearances.  Organize  a  master  list  of  all  local  participant  per¬ 
sonnel.  Visitation  badges  were  of  the  following  types: 

1 .  Escort  required. 

2.  Limited  access  to  SEAF  and  SIMNET. 

3.  Unlimited  access  (not  necessary  for  most  participants). 

c.  Provide  perimeter  control  (razor  wire  surrounded  the  SEAF). 

d.  Provide  24-hour  guards  at  SEAF  entrances. 

e.  Coordinate  VIP  visits  (daily  visitor  list). 

f.  Execute  disk  sanitization/chip  destruction  at  the  end  of  STOW-E.  (Provided  certifications  of 
destruction  and  disk  erasure  prior  to  shipping.  Provided  Customs  forms  for  overseas  equip¬ 
ment  shipping.) 

4.2.5  Black  Sites 

N/A. 

4.2.6  Red  Sites 

The  following  is  a  list  of  criteria  that  all  Red  sites  met  for  STOW-E. 

a.  DSI  node  installation/training:  All  DSI  nodes  were  installed  by  qualified  DSI  personal,  and 
DSI  hands-on  training  was  made  available  to  all  STOW-E  participants.  This  training  was 
strongly  recommended  and  proved  to  be  highly  useful  for  network  coordination  and  trouble¬ 
shooting  prior  to  and  during  STOW-E. 

b.  INES  training:  Highly  useful  1-week  training  (ARPA  sponsored)  covering  encryption  devise 
use  and  operation.  Attendance  at  a  3-day  Motorola  INES  course  in  Phoenix,  AZ,  for  at  least 
one  individual  at  each  Red  STOW-E  site  was  also  recommended. 

c.  Individual  facility  authorization  to  operate  in  a  dedicated  mode  (listed  in  MOA):  Each  DSI 
node  site  agreed  to  dedicate  the  use  of  all  DSI  equipment  during  STOW-E  to  the  actual  tasks 
of  STOW-E. 

d.  Communications  security  Material  Systems  (CMS)  accounts  in  place  and  trained,  approved 
CMS  personnel  in  place  and  available  at  all  Red  STOW-E  sites. 

e.  Personnel  access  lists  for  all  secure  areas  in  place. 

f.  NES  configuration  disks  and  keys  distributed  from  DSI  management. 

g.  NSA-approved  classified  storage  available  at  all  Red  sites. 

h.  Site  visitors:  Red  site  clearances  and  Black  visitor  requests  were  sent  prior  to  the  beginning  of 
STOW-E  testing. 


4.2.7  Results 

The  Security  Guard  worked  as  planned,  designed,  approved,  and  engineered.  Early  recognition 
of  security  issues  and  appropriate,  early,  and  thorough  action  to  mitigate  security  risks  were 
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instrumental  in  making  security  a  non-issue  for  STOW-E.  However,  for  future  STOW  demonstra¬ 
tions/exercises,  the  INES  and  the  Guard  should  be  reviewed  to  determine  if  they  are  adequate  for 
large  and  more  complex  exercises.  They  probably  are  not  sufficient. 

4.3  TACTICAL  COMMUNICATIONS 

4.3.1  Introduction 

This  section  describes  the  communications,  external  to  the  simulation  data  network,  connecting  the 
simulations/simulators  and  live  sites  required  to  provide  simulated  Tactical  Radio  Nets.  These  com¬ 
munications  simulate,  as  realistic  as  possible,  the  Tactical  Radio  nets  that  would  be  in  use  in  a  The¬ 
ater  of  Operations.  Also  provided  for  were  any  Data  Links  that  were  not  subsumed  in  the  simula¬ 
tions  or  simulators.  The  communications  described  here  were  over  and  above  that  provided  by  the 
participating  units’  organic  equipment.  Further,  communications  that  were  internal  to  the  participat¬ 
ing  facilities  were  not  considered.  This  section,  in  addition  to  describing  the  configuration,  evaluates 
the  performance  of  the  process  and  planning  for  the  Tactical  Communications. 

4.3.2  Configuration 

The  purpose  of  the  Support  and  Tactical  Communications  was  to  provide  the  nondata  communica¬ 
tions  support  required  for  the  demonstrations.  The  Nets  were  organized  to  simulate  Tactical  Radio 
Nets  that  would  be  found  in  use  by  the  Tactical  units  simulated.  These  nets  are  normally  HF/VHF/ 
UHF  clear  voice  and  1/2  duplex;  push  to  talk.  This  operation  was  accommodated  by  providing  audio 
teleconference  calls  to  replicate  the  nets  using  DSN  and  FTS  bridges.  Commercial  conferencing  was 
to  be  used  if  the  preemption  rate  was  high  or  intolerable. 

Each  subscriber  normally  used  a  standard  speakerphone.  In  some  cases,  where  the  activity  was 
predicted  to  be  high  a  particular  site  and  high  ambient  noise  existed,  a  headset  was  provided.  A 
headset  was  provided  for  personnel  using  consoles  or  operating  simulators.  The  default  mode  for  the 
subscriber  was  to  have  the  speakerphone  on  and  muted.  The  muting  was  very  important  to  keep  the 
background  noise  on  the  net  at  a  minimum.  When  a  subscriber  was  active,  the  built-in  microphone 
or  the  handset  could  be  used.  For  some  Tactical  Communications  Nets,  actual  connection  into  the 
headsets  of  simulators  was  provided. 

4.3.3  Evaluation 

4.3.3.1  Planning.  The  generation  of  the  Tactical  Communications  Plan  was  completed  without 
undue  effort.  The  primary  inputs  were  the  scenarios  and  Order  of  Battle  for  the  demonstration.  The 
gathering  of  the  telephone  numbers  to  be  used  during  the  test  was  the  major  challenge.  Many  sites 
had  to  procure  additional  lines,  so  the  numbers  were  provided  at  the  last  minute.  Since  there  was  no 
extra  effort  required  after  receipt  of  the  numbers  and  actual  implementation  of  the  nets,  this  did  not 
present  any  problem.  The  number  of  revisions  was  high  since  the  sites  rearranged  their  facilitates 
from  time  to  time.  All  in  all,  the  planning  went  well. 

4.3.3.2  Implementation.  The  implementation  was  accomplished  by  using  the  DSN  for  all  confer¬ 
ence  calls  involving  overseas  subscribers.  FTS  was  used  to  support  all  CONUS-only  conference 
calls.  MCI  Forum  was  available  for  backup.  The  reason  DSN  was  used  was  cost  considerations  and 
because  FTS  does  not  cover  outside  CONUS  calls.  The  original  plan  was  to  use  DSN  for  all  confer¬ 
ences,  but  it  became  apparent  during  the  preparatory  tests  that  the  conference  operators  would  not  be 
able  to  handle  all  of  our  conferences  at  the  peak  of  the  demonstration,  as  well  as  the  other  normally 
occurring  conference  calls.  It  was  then  decided  to  use  FTS  even  though  it  was  not  reimbursable. 
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The  implementation  was  technically  acceptable  in  that  the  conference  bridges  worked,  and  the  con¬ 
nectivity  was  achieved  with  few  problems.  The  shortcomings  will  be  discussed  below.  As  far  as  the 
terminal  equipment  was  concerned,  the  sites  used  speakerphones  with  mute  switches.  In  the  case  of 
Hue  City,  cellular  phones  were  used. 

4.3.3.3  Shortcomings.  The  use  of  the  speakerphones  did  not  replicate  normal  tactical  radio  equip¬ 
ment  and,  in  that  sense,  was  somewhat  unrealistic.  To  provide  for  tactical  hardware  would  have 
required  additional  engineering  effort  and  hardware  cost. 

None  of  the  circuits  was  covered;  hence  the  voice  communications  were  “in  the  clear.”  In  some 
instances  had  secure  voice  been  provided,  more  realism  could  have  been  achieved.  This  was  consid¬ 
ered  but,  for  STOW-E,  was  not  warranted  by  the  cost/benefit  balance. 

Use  of  the  DSN  caused  preemption  in  some  cases,  which  interrupted  operations.  Restoration  had 
to  be  accomplished  by  the  disconnected  party.  The  conferences  were  established  at  the  IMMEDI¬ 
ATE  precedence  level,  and  if  a  disconnected  party  was  at  a  ROUTINE  instrument,  the  party  would 
be  reconnected  at  ROUTINE  precedence  making  preemption  more  of  a  recurring  possibility.  Other¬ 
wise  the  operator  had  to  disconnect  the  party  and  reconnect  at  the  IMMEDIATE  level  creating  inor¬ 
dinate  delays.  Overall,  however,  preemption  on  DSN  was  minimal  (10  to  15%). 

The  lack  of  training  for  the  Voice  Net  Control  Stations  (NCSs)  caused  confusion  and  conflicts  at 
the  beginning  of  testing.  On  the  job  training  was  used  to  bring  the  various  Nets  on  line.  Had  some 
formal  training  been  provided,  this  could  have  been  smoother.  By  the  time  the  demonstration  was 
started,  the  NCSs  were  adept  at  their  tasks. 

4.4  TECHNICAL  CONTROL 

4.4.1  Introduction 

This  area  of  responsibility  entailed  functions  relating  to  the  operation  of  STOW-E  hardware  and 
software  located  in  the  SEAF  at  Grafenwoehr,  Germany,  and  at  participating  sites,  with  the  exception 
of  communications  and  data  analysis  functions. 

4.4.2  SEAF  Technical  Control  Stations 

SEAF  Technical  Control  was  defined  by  the  stations  manned  during  STOW-E.  These  stations  and 
their  functions  were  as  follows: 

4.4.2.1  Technical  Control  Manager.  This  position  had  overall  responsibility  for  the  technical 
control  section  of  the  SEAF  and  technical  coordination  of  all  network  participating  sites.  This 
responsibility  extended  to  a  high-level  defining  of  objectives  directly  supporting  STOW-E  program 
goals.  The  Technical  Control  Manager  managed  resources  (fiscal,  equipment,  personnel,  and  sched¬ 
ule)  and  provided  program  review  continuity  in  the  technical  control  section  area.  During  test,  tech¬ 
nical,  and  exercise  periods,  the  Technical  Control  Manager  was  located  at  the  SEAF,  the  NOC,  or 
any  other  participating  site.  When  the  Technical  Control  Manager  was  not  at  the  SEAF,  the  Techni¬ 
cal  Control  Supervisor  performed  the  SEAF  on-site  functions. 

4.4.2.2  Technical  Control  Supervisor.  This  position  was  responsible  for  directing  and  coordinat¬ 
ing  the  activities  of  all  participating  sites  and  of  the  SEAF.  This  included  arranging,  initiating,  and 
maintaining  technical  control  and  engineering  conference  calls;  ensuring  DSI  reservations  were 
made  by  the  DSI  Network  Manger  for  test  and  scenario  events;  conducting  all  planned  technical  test 
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events  as  listed  in  the  appropriate  test  plans  and  procedures;  and  preparing  narrative  logs  and  reports 
after  completion  of  technical  test  events. 

4.4.2.3  Network  Supervisor.  The  Network  Supervisor  was  responsible  for  overall  network  opera¬ 
tions  and  continuity,  including  supervising  equipment  procurement,  shipment,  installation,  and 
checkout;  software  management  including  managing  the  Application  Gateway  engineers  and  coor¬ 
dination  with  DIS  engineers;  maintaining  site  ID  number  status;  and  coordinating  technical  opera¬ 
tions  with  test  operations  directed  by  the  Technical  Control  Supervisor. 

4.4.2.4  DSI  Operations  Engineers.  This  position  provided  hardware  and  software  support  for 
unclassified  and  classified  operations  including  equipment  procurement,  shipment,  installation,  and 
checkout.  During  SEAF  operations,  the  DSI  Operations  Engineers  ensured  continuity  of  the  unclas¬ 
sified  and  classified  networks  through  system  monitoring,  operation,  and  troubleshooting,  as  well  as 
by  close  coordination  with  the  NOC.  DSI  engineers  were  responsible  for  INES  operations  on  the 
classified  networks  including  initialization  and  configuration  disk  management;  and  for  Video  Tele¬ 
conferencing  (VTC)  equipment,  operation,  and  scheduling. 

4.4.2.5  Application  Gateway  Engineer.  This  position  was  responsible  for  supporting  the  AG 
software  at  the  SEAF  and  other  sites,  to  include  software  debugging,  writing  necessary  software 
patch  programs,  configuration  management  and  documentation.  This  engineer  was  also  responsible 
for  monitoring  AG  performance  and  evaluating  AG  software  performance,  and  providing  application 
gateway  technical  support  to  site  general  engineers. 

4.4.2.6  Net  Visualizer  Analyst.  This  position  supported  the  real-time  monitoring  and  collecting 
of  traffic  load  data  at  each  site  on  the  network  in  direct  support  of  the  Network  Supervisor  and  DSI 
Operations  Engineers,  as  well  as  for  subsequent  data  analysis  to  assess  network  performance.  This 
analyst  also  supported  occasional  tour  discussions  of  the  Net  Visualizer  functions  and  how  these 
functions  supported  network  operations. 

4.4.2.7  Stealth  Operator.  This  position  supported  the  Technical  Control  Supervisor  and  scenario 
direction  by  operating  a  3-D  display  of  any  aspect  of  the  battlefield.  Actions  ranged  from  tagging 
onto  an  individual  combat  unit  to  scanning  large  areas  of  the  battlefield.  The  Stealth  Operator  also 
supported  all  appropriate  inquiries  from  other  SEAF  participants,  as  well  as  tour  individuals  and 
included  illustrating  the  capabilities  and  uses  of  the  3-D  display  and  explaining  battlefield  activities. 
These  responsibilities  required  the  Stealth  Operator  to  remain  up-to-date  on  scenario  and  interaction 
activities. 

4.4.2.8  Army  Site  Status  Projection  Operator.  This  position  ensured  that  status  projection 
information  was  current  and  complete  for  all  Army  operations  so  that  it  could  be  used  by  all  other 
sections  (Headquarters  and  Administration  Support,  Operations,  Scenario,  and  Communications 
Control).  The  operator  was  also  charged  with  using  this  projection  to  brief  varying  levels  of  tour 
participants,  both  military  and  civilian. 

4.4.2.9  Navy  Site  Status  Projection  Operator.  This  position  ensured  that  status  projection 
information  was  current  and  complete  for  all  Navy  Operations  so  that  it  could  be  used  by  all  other 
sections  (Headquarters  and  Administration  Support,  Operations,  Scenario,  and  Communications 
Control).  The  operator  was  also  charged  with  using  this  projection  to  brief  varying  levels  of  tour 
participants,  both  military  and  civilian. 

4.4.2.10  Air  Force  Site  Status  Projection  Operator.  This  position  ensured  the  status  projection 
information  was  current  and  complete  for  all  Air  Force  operations  for  use  by  all  other  sections 
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(Headquarters  and  Administration  Support,  Operations,  Scenario,  and  Communications  Control). 
The  operator  was  also  charged  with  using  this  projection  to  brief  varying  levels  of  tour  participants, 
both  military  and  civilian. 

4.4.2.11  Technologies  Status  Projection  Operator.  This  position  managed  the  technologies 
status  display  showing  operational  states  of  the  merging  technologies  being  used  in  STOW-E.  This 
position  required  in-depth  knowledge  of  these  technologies  to  respond  to  inquiries  from  a  variety  of 
tour  participants.  Such  technical  briefs  accommodated  varying  levels  of  tour  participant  knowledge 
and  interests. 

4.4.2.12  Stealth  3-D  Naval  Shipping  Operator.  This  position  supported  the  Technical  Control 
Supervisor  and  scenario  direction  by  operating  a  3-D  display  of  the  naval  operating  area.  Duties 
ranged  from  tethering  onto  individual  ships  to  scanning  large  areas  of  the  ocean.  The  Stealth  3-D 
Naval  Shipping  Operator  also  supported  all  appropriate  inquiries  from  other  SEAF  participants,  brief 
groups,  and  individuals  and  was  called  on  to  explain  the  capabilities  and  uses  of  the  3-D  display  as 
well  as  naval  shipping  activities.  These  responsibilities  required  the  Stealth  3-D  Naval  Shipping 
Operator  to  remain  up-to-date  on  scenario  and  interaction  activities. 

4.4.2.13  Stealth  3-D  Navy/Air  Force  Operator.  This  position  supported  the  Technical  Control 
Supervisor  and  scenario  direction  by  operating  a  3-D  display  of  the  Navy /Air  Force  aircraft  operat¬ 
ing  area.  Duties  ranged  from  tethering  onto  individual  aircraft  to  scanning  large  air  operations  areas. 
The  Stealth  3-D  Navy/ Air  Force  Aircraft  Operator  also  supported  all  appropriate  inquiries  from  other 
SEAF  participants,  brief  groups,  and  individuals  and  was  called  on  to  explain  the  capabilities  and 
uses  of  the  3-D  display  as  well  as  Navy  and  Air  Force  activities.  These  responsibilities  required  the 
Stealth  3-D  Navy/Air  Force  Aircraft  Operator  to  remain  up-to-date  on  scenario  and  interaction  acti¬ 
vities. 

4.4.2.14  DSI  Network  Status  Projection  Operator.  This  Operator  ensured  the  status  projection 
information  was  current  and  complete  for  all  DSI  operations  for  use  by  all  other  sections  (Headquar¬ 
ters  and  Administration  Support,  Operations,  Scenario,  and  Communications  Control)  and  was 
responsible  for  using  this  projection  to  brief  varying  levels  of  tour  participants,  both  military  and 
civilian. 

4.4.3  Briefing  Operations 

Descriptions  of  STOW-E  technologies  and  techniques  were  necessary  when  considering  the 
aspects  of  program  verification  and  exposure  to  actual  and  potential  users  of  STOW-E  technologies. 

A  comprehensive  effort  in  demonstrating  STOW-E  concepts  was  directed  in  the  SEAF  by  the  Opera¬ 
tions  Section  and  consisted  of  static  and  dynamic  displays  supported  by  the  on-going  exercises  and 
scenarios  and  a  team  of  trained  briefers.  Briefers,  assisted  by  members  of  the  Technical  Control  Sec¬ 
tions,  performed  functions  within  their  areas  of  responsibilities  to  support  individual  briefing  con¬ 
cerns  and  questions.  Members  of  the  Technical  Control  Team  remained  aware  of  how  their  areas  of 
responsibility  supported  both  the  SEAF  and  STOW-E  concepts  and  goals  and  were  able  to  articulate 
such  information  to  individuals  and  groups.  All  Technical  Control  Team  members  reviewed  each 
day’s  expected  Joint  Visitors  Bureau  requirements  prior  to  assuming  their  duties  and  were  prepared 
for  unannounced  briefing  requirements. 

4.5  DATA  COLLECTION  AND  ANALYSIS 
4.5.1  Background 

STOW-E  analysis  was  divided  into  three  areas:  technical  analysis,  real-time  and  after-action  sce¬ 
nario  review,  and  operational  analysis.  Technical  analysis  addresses  the  performance  of  the  DSI 
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network  and  the  various  systems  and  simulations  operating  on  the  network.  Real-time  and  after-ac¬ 
tion  scenario  reviews  assess  the  execution  of  the  military  scenario.  Operational  analysis  addresses 
the  effectiveness  of  the  military  training  of  the  demonstration. 

NRaD’s  data  analysis  efforts  were  focused  on  technical  issues.  Technical  analysis  included  the 
assessment  of  the  performance  of  the  AG,  the  characterization  of  DIS  traffic,  and  the  estimation  of 
delays  across  the  network.  The  individual  site  DIS  data  log  files,  which  were  recorded  at  most  sites, 
are  available  to  support  military  after-action  reviews.  Los  Alamos  National  Labs  is  merging  individ¬ 
ual  site  files  to  construct  complete,  ground-truth  log  files  for  selected  portions  of  STOW-E.  This 
composite  file  will  also  support  military  after-action  review.  Operational  analysis  is  being  conducted 
by  the  7th  Army  in  Grafenwoehr,  Germany,  and  by  designated  Navy  and  Air  Force  analytical  facili¬ 
ties  such  as  the  Center  for  Naval  Analysis  (CNA). 

4.5.2  Data  Collection 

4.5.2.1  Site  Configurations.  The  NRaD  DIS  Data  Logger  (DLogger)  was  used  to  record  the  DIS 
traffic  during  STOW-E.  Data  was  recorded  on  the  local  simulation  LAN  at  each  STOW-E  site  (with 
the  exception  of  Dahlgren).  A  DLogger,  running  on  an  SGI  platform,  was  a  node  on  the  local  LAN 
and  was  configured  to  record  all  appropriate  DIS  traffic  (exercise  ID  3  for  Red  sites  and  2  for  Black 
sites).  The  recorded  data  thus  consists  of  the  data  generated  locally  and  the  data  presented  to  the 
LAN  via  the  AG.  Table  4-1  lists  all  DLogger  sites.  Figure  4-1  illustrates  the  configuration  of  a  typi¬ 
cal  Red  STOW-E  site. 


Table  4-1 .  DLogger  Sites. 


Red  DLogger  Sites 

Black  DLogger  Sites 

TACCSF  (Albuquerque,  NM) 

AVTB  (Ft.  Rucker,  AL) 

NUWC  (Newport,  Rl) 

SIMNET  (Grafenwoehr,  Germany) 

WISSARD  (Virginia  Beach,  VA) 

BFTT  (Damneck,  VA) 

SEAF  (Grafenwoehr,  Germany) 

IDA  (Alexandria,  VA) 

NAWC  (Cherry  Pt„  NC) 

MFS  (Patuxent  River,  MD) 
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Figure  4-1.  Typical  Red  site  configuration. 

In  addition  to  recording  simulation  LAN  traffic,  the  two  Black  sites  (Ft.  Rucker  and  SIMNET) 
logged  data  on  the  WAN  side  of  the  AG.  This  was  done  using  a  slightly  modified  DLogger.  This 
second  logger,  the  AGWANReceiver,  recorded  all  UDP  port  3000  traffic.  The  intent  of  logging  this 
data  was  to  provide  a  means  of  directly  analyzing  the  performance  of  the  AG  at  these  two  sites. 
Figure  4-2  illustrates  the  configuration  at  the  two  Black  sites. 


PS  I  BACKBONE 


Figure  4-2.  Black  site  (Ft.  Rucker  and  SIMNET)  configuration. 

The  SEAF,  in  Grafenwoher,  Germany,  also  logged  selected  LAN  and  WAN  network  traffic  using 
SGI’s  Network  Visualizer  software.  The  configuration  at  the  SEAF  is  illustrated  in  figure  4-3.  BBN 
monitored  loads,  packets  dropped,  errors,  etc.,  by  using  its  Advanced  Network  Monitoring  tool. 
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Figure  4-3.  SEAF  configuration. 

4.5.2.2  DLogger  Specifics.  DLogger  records  DIS  PDUs  along  with  a  time-stamp  corresponding 
to  when  the  PDU  was  detected  by  on  the  LAN.  This  time-stamp  is  crucial  to  the  accurate  analysis  of 
the  log  files.  Comparing  this  time-stamp  to  the  time-stamp  found  within  the  data  of  the  DIS  PDU  is 
a  means  by  which  a  simulator’s  PDU  generation  rate  can  be  verified.  This  technique  was  used  in 
Newport  to  confirm  that  PDUs  from  a  particular  BFTT  entity  were  being  heard  on  the  NUWC  LAN 
at  the  proper  ~5-second  heartbeat  interval.  The  DLogger  time-stamp  also  makes  possible  the  realis¬ 
tic  playback  of  PDUs  from  a  log  file. 

4.5.3  Technical  Analysis 

4.5.3.1  Bandwidth-Demand  Reduction  Techniques  (BRTs).  The  bandwidth-demand  reduction 
techniques  (BRTs)  were  housed  in  the  AG  component  of  the  DSI  network.  The  function  of  these 
algorithms  in  STOW-E  was  to  reduce  the  DIS  traffic  load  offered  to  the  DSI  WAN.  The  perfor¬ 
mance  of  the  STOW-E  AG  will  be  assessed  from  the  following  viewpoints: 

a.  Overall  AG  system  performance 

b.  AG  performance  at  selected  individual  sites 

c.  Performance  of  individual  AG  algorithms 

“Real-time”  estimates  of  overall  AG  system  performance,  as  well  as  the  performance  of  some  indi¬ 
vidual  algorithms  were  collected  during  STOW-E.  See  section  3.3  for  this  data. 

4.5.3.2  Characterization  of  the  DIS  Traffic.  Characterization  of  DIS  traffic  loads  is  critical  for 
network  bandwidth  allocation  in  future  DIS  exercises.  DIS  simulation  load  is  a  function  of  the  simu¬ 
lation  system,  the  number  and  types  of  entities  being  generated,  the  entities’  levels  of  activity,  and 
the  dead-reckoning  algorithm  being  used.  Samples  of  STOW-E  traffic  will  be  so  characterized.  This 
analysis  will  include  initial  correlations  of  load  with  the  military  scenario. 

4.5.3.3  Network  Delay.  DSI  network  delay  will  be  estimated  for  selected  segments/periods  of  the 
STOW-E  exercise.  Due  to  the  volume  of  STOW-E  data  collected  (approximately  24  Mb)  and  the 
time  required  for  its  analysis,  a  separate  data  analysis  report  will  be  published  at  a  later  date. 
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4.6  TEST  AND  INTEGRATION 


4.6.1  General 

Test  and  Integration  covers  the  STOW-E  test  efforts  from  April  through  November  1994  includ¬ 
ing:  STOW-E  planning  meetings,  Subsystem  Integration  Tests  (SSITs),  Review  and  Planning  meet¬ 
ings,  Functional  Validation  (FV)  Tests,  System  Integration  Tests  (SITs),  and  the  STOW-E  technology 
demonstration. 

4.6.2  Original  Test  and  Integration  Plan 

The  integration  of  sites  for  STOW-E  was  originally  planned  as  generically  as  possible  to  accom¬ 
modate  the  introduction  of  new  technology  and  individual  site  requirement  changes  that  were  antici¬ 
pated  to  occur  throughout  the  test  effort.  As  the  SSITs  were  accomplished  and  requirements  became 
more  clearly  defined,  associated  documentation  became  more  detailed  and  specific.  This  worked 
well  as  a  point  of  departure  and  supported  the  STOW-E  test  and  integration  process.  As  emerging 
requirements  became  known  and  modifications  to  existing  requirements  became  more  clearly 
defined,  they  replaced  the  generic  statements  in  the  test  plan  and  procedures.  Many  of  the  detailed/ 
specific  requirements  were  not  available  when  the  test  and  integration  process  began. 

4.6.2.1  Planning  Meeting.  The  Naval  Command,  Control  and  Ocean  Surveillance  Center 
(NCCOSC)  RDT&E  Division  (NRaD)  hosted  a  STOW-E  program  planning  meeting  for  all  site  rep¬ 
resentatives.  During  this  meeting,  the  System  Engineering  and  Integration  (SEI)  Test  Coordinator 
outlined  the  plan  for  the  STOW-E  Test  and  Integration  effort.  The  test  organization  was  introduced, 
test  terms  and  milestones  were  identified  and  defined,  SEI  points-of-contact  were  established  for 
each  of  the  known  participating  sites.  Unique  site  requirements  and  current  schedules  were 
requested  from  each  site.  Tentative  scheduling  for  all  tests  were  distributed  to  all  site  representatives 
in  attendance.  The  testing  described  included  Unit  Testing,  DIS  Version  2.0.3  Compliance  Testing, 
Subsystem  Integration  Testing,  and  System  Integration  Testing. 

4.6.2.2  Requirements  Development.  A  preliminary  test  requirements  list  was  developed  using 
the  STOW-E  System  Requirements  Document  as  a  starting  point.  Exit  criteria  and  measures  of  suc¬ 
cess  were  developed  specifically  for  each  requirement.  Site  modifications  were  planned  to  be  incor¬ 
porated  as  the  Test  Coordinator  received  them. 

4.6.2.3  Test  Plan/Procedure  Development.  The  test  plan  and  procedure  format  evolved  out  of 
the  preliminary  meetings.  This  format  included  the  following  sections:  General,  Dates,  Times, 

Scope,  Concept,  Test  Objectives,  Test  Execution,  System  Failure  Procedures,  Exercise  Support,  and 
Appendices.  This  document  was  distributed  to  all  sites.  In  the  beginning,  the  document  was  fairly 
small  and  was  distributed  to  participating  sites  via  telephonic  facsimile.  As  the  document  necessarily 
grew  in  size  with  the  addition  of  sites  to  each  test  period,  it  was  more  expedient  and/or  cost  effective 
to  use  Federal  Express  and/or  US  Express  Mail.  The  final  process  involved  distributing  the  docu¬ 
ments  using  the  File  Transfer  Protocol  (FTP)  on  the  DSI  Network  and/or  the  Internet,  which  proved 
much  more  practical  and  effective. 

4.6.2.4  Supporting  Reference  Notes.  Supporting  reference  notes  were  compiled  for  each  site 
showing  the  Points  of  Contact  (POCs),  DSI  node  status,  entity-generation  capability,  DlS-com- 
pliance  status,  and  DSI  node  IP  addresses.  The  site  POCs  were  used  as  addressees  for  distribution  of 
e-mail,  faxes,  and  test  documentation. 

Schedules  were  developed  and  maintained  to  show  upcoming  events  such  as  SSITs,  major  concur¬ 
rent  military  exercises,  scheduled  site  participation,  and  site  DIS  node  installation  status.  Master 
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schedules  were  generated  and  displayed  at  NRaD  and  used  as  the  basis  for  test  planning  and  coor¬ 
dination  of  associated  activities. 

4.6.3  Real-Time  STOW-E  Modifications 

4.6.3.1  General.  Flexibility  became  a  major  part  of  the  test  planning.  As  STOW-E  became  more 
visible,  requirements  changed.  New  technologies  were  incorporated  as  they  were  developed,  or  were 
enhanced  after  they  were  incorporated.  These  changes,  though  not  foreseen  in  detail,  were  antici¬ 
pated.  Consequently,  the  STOW-E  effort  followed  the  original  plan  very  closely.  Changes  were 
quickly  incorporated  to  keep  pace  with  the  demands  of  meeting  the  STOW-E  compressed  time 
schedule. 

4.6.3.2  Requirements.  Requirements  became  more  clearly  defined  as  sites  began  to  participate 
and  test  their  systems.  Requirements  were  also  defined  and  modified  by  the  presiding  members  of 
the  Joint  Services.  Development/modification  of  requirements  for  hardware,  software,  and  testing 
were  constantly  evolving.  Requirements  were  kept  current  as  new  information  was  made  available 
to  the  test  team. 

4.6.3.3  Schedules.  SSITs  were  executed  with  only  minor  departure  from  the  original  plan.  Three 
SSITs  were  extended  in  time  from  the  original  plan;  one  SSIT  was  added  to  the  original  plan;  and  the 
SIT  was  moved  up  and  incorporated  into  SSIT  #8.  Table  4-2  shows  planned  versus  actual  test  dates. 
It  became  extremely  difficult  to  make  plans  and  schedules,  incorporate  them  into  the  test  documenta¬ 
tion,  distribute  them  in  time  to  allow  for  review  and  comment,  and  then  incorporate  those  comments 
and  redistribute  the  revisions  to  all  sites  before  the  actual  test  was  executed.  Future  scheduling 
should  learn  from  this  lesson  and  allow  additional  time  between  scheduled  test  periods. 


Table  4-2.  Test  schedule  summary. 


Test  Dates 

Event 

Planned 

Actual 

SSIT  #1 

5-7  April 

5—7  April 

SSIT  #2 

17-19  May 

17— 19  May 

SSIT  #3 

8-10  June 

21-23  June 

SSIT  #4/FV-1 

11-15  July 

8-15  July 

SSIT  #5 

8-1 2  August 

8-12  August 

SSIT  #6 

25-30  August 

SSIT  #7/FV-2 

12-16  September 

9-17  September 

SSIT  #8 

3-7  October 

3-7  October 

SIT 

11-13  October 

i 

FV-3 

23-27  October 

STOW-E 

4-7  November 

4-7  November 

4.6.3.4  Site  Changes.  The  original  list  of  sites  was  developed  based  on  the  known  schedule  of 
site  availability  and  DIS  2.0.3  compliance  readiness.  Table  4-3  shows  the  original  list  of  sites 
compared  to  the  actual  list  of  sites  participating  in  STOW-E.  Sites  are  shown  with  their  abbreviated 
name  and  site  location. 
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Table  4-3.  STOW-E  sites. 


Planned 

Actual 

ACMI,  Nellis  AFB,  Las  Vegas,  NV 

AEGIS,  Mayport,  FL 

AEGIS,  Mayport,  FL 

Armstrong  Lab,  Williams  AFB,  AZ 

Armstrong  Lab,  Williams  AFB,  AZ 

AVTB,  Ft.  Rucker,  Dothan,  AL 

Artillery,  Ft.  Sill,  OK 

BFTT,  Dam  Neck,  VA 

AVTB,  Ft.  Rucker,  Dothan,  AL 

BBS,  Hohenfels,  GE 

BFTT,  Dam  Neck,  VA 

CMTC-IS,  Hohenfels,  GE 

BBS,  Hohenfels,  GE 

IDA,  Arlington,  VA 

CMTC-IS,  Hohenfels,  GE 

NAWC-AD,  Patuxent  River,  MD 

Ft.  Monroe,  VA 

NSWC-DD,  Dahlgren,  VA 

IDA,  Arlington,  VA 

NUWC,  Newport,  Rl 

NAWC-AD,  Patuxent  River,  MD 

Pentagon,  Washington,  DC 

NRaD,  San  Diego,  CA 

RAF,  Lakenheath,  UK 

NTCS-A,  Orlando,  FL 

SEAF,  Grafenwoehr,  GE 

NUWC,  Newport,  Rl 

SIMNET,  Grafenwoehr,  GE 

Pentagon,  Washington,  DC 

TACCSF,  Kirtland  AFB,  NM 

SEAF,  Grafenwoehr,  GE 

TACTS,  Cherry  Point,  NC 

SIMNET,  Grafenwoehr,  GE 

USAF  Falcon  Star,  Grafenwoehr,  GE 

Spangdahlem,  GE 

TACCSF,  Kirtland  AFB,  NM 

TACTS,  Cherry  Point,  NC 

Williams  AFB,  AZ 

WISSARD,  NAS  Oceana,  VA 

Warrior  Preparation  Center  (WPC),  Einsiedlerhof,  GE 

WISSARD,  NAS  Oceana,  VA 

4.6.3.5  Test  Plan/Procedures 

4. 6.3.5. 1  Test  Process.  The  original  plan  called  for  sites  to  successfully  complete  their  own  unit 
testing  before  being  added  to  an  SSIT.  This  was  intended  to  preclude  using  valuable  integration  time 
to  troubleshoot  individual  site  simulators/simulations.  Most  sites  complied  and  when  problems  were 
discovered  they  were,  for  the  most  part,  unique  to  having  other  sites  on  the  network  (e.g.,  translator 
incompatibilities,  database  incompatibilities).  DIS  2.0.3  compliance  testing  was  originally  planned 
to  be  completed  using  the  methodology  developed  in  the  DIS  testbed  at  the  University  of  Central 
Florida  (UCF).  Some,  but  not  all,  DIS  compliance  testing  was  completed. 

After  SSIT  #3,  POCs  attended  a  combined  post-SSIT  review  and  pre-SSIT  planning  meeting  to  dis¬ 
cuss  lessons  learned  during  the  last  SSIT  as  well  as  enhancements  needed  for  the  next  SSIT.  These 
meetings  proved  beneficial  for  a  quick  evaluation,  and  for  discussing  the  practicality  of  new  ideas 
presented,  and  for  providing  much  needed  face-to-face  meetings  for  participants. 

4.6. 3.5. 2  Test  Plan/Procedures  Document.  Each  test  plan  was  based  on  the  most  recent  definition 
of  project  requirements.  Changes  from  each  SSIT  were  incorporated  into  the  next  test  plan  and  pro¬ 
cedures  document.  When  sites  did  not  send  in  their  test  requirements  but  did  voice  a  need,  the  test 
team  made  its  best  effort  to  incorporate  those  needs.  The  test  document  distribution  process  was 
being  modified  as  the  test  evolution  unfolded  and  as  new  distribution  methods  became  available. 
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4. 6.3. 6  Trouble  Reports.  A  trouble  report  process  was  incorporated  into  the  test  effort.  Any  site 
or  individual  could  write  up  a  problem  on  the  STOW-E  trouble  report  (TR)  form.  The  TR  was  sub¬ 
mitted  to  NRaD  for  action/dissemination.  The  TR  was  entered  on  a  database  to  track  its  progress. 
Each  final  test  report  included  the  TR  log  for  that  SSIT  as  one  of  the  appendices.  The  TR  log 
included  in  the  Test  Report  for  SSIT  #8  has  a  compilation  of  all  SSIT  TRs  from  April  through  Octo¬ 
ber. 

4.6.3.7  Test  Reports.  During  each  SSIT,  activity  logs  were  kept  with  as  much  detail  as  practical 
for  the  log  keeper.  At  the  end  of  the  day,  all  sites  faxed  their  logs  to  NRaD,  and  the  test  team  com¬ 
piled  a  daily  report.  At  the  end  of  the  test,  a  quick  look  report  was  written  and  distributed. 

After  the  conclusion  of  an  SSIT,  a  test  report  was  written.  Each  test  requirement  for  that  particular 
SSIT  was  reviewed  with  respect  to  the  established  exit  criteria  and  measures  of  success.  Conclusions 
were  summarized  based  on  general  and  specific  results.  The  DSI  network  reliability  summary  was 
also  included.  Appendices  included  such  items  as  quick  look  reports,  daily  test  logs,  trouble  report 
log,  and  acronyms. 

4.6.4  Final  Product:  STOW-E 

The  test  team  duties  for  STOW-E  were  to  provide  support  in  the  preparation  and  manning  of  the 
SEAF  for  the  STOW-E  demonstration.  The  test  team  originally  planned  for  24-hour  coverage,  which 
proved  unnecessary.  Manning  hours  were  kept  flexible  to  cope  with  changing  requirements.  Testers 
aided  in  hardware  setup  and  installation,  software  loading  and  testing,  support  for  the  AG  testing, 
manning  the  Technical  Control  telephone  conference,  sending  out  daily  DSN  telephone  conference 
requests  to  the  DSN  Operator,  keeping  the  daily  activity  logs,  updating  Army,  Navy,  and  Air  Force 
site  status  boards,  helping  with  scenario  development  and  replay,  and  other  miscellaneous  support. 

4.6.5  Lessons  Learned  and  Conclusions 

4.6.5. 1  Meetings.  Even  with  all  the  last-minute  meetings  and  last-minute  changes,  the  final  SSITs 
and  STOW-E  were  not  much  different  than  originally  planned.  The  meetings  could  have  been  mini¬ 
mized  and  time  could  have  been  better  spent  working  the  plan  rather  than  replanning  the  work. 

4.6.5.2  Test  Bed.  During  the  SSITs,  the  computer  assets  in  the  NRaD  test  laboratory  were  shipped 
all  over  the  world  to  support  hardware  requirements  at  other  sites.  The  end  result  of  not  having  a 
stable  test-bed  environment  for  the  NRaD  test  team  was  that  the  test  team  had  to  travel  extensively  to 
other  sites. 

4.6.5.3  Manning.  Some  SSITs  were  well-manned  at  all  sites  while  other  SSITs  operated  with  only 
a  skeleton  crew  at  certain  sites.  The  optimum  test  team  size  was  five  people.  One  person  for  Test 
Coordinator  (to  handle  the  conference  call  telephone  and  coordinate  test  activities  at  the  site);  one 
person  to  maintain  the  daily  activity  log;  one  person  to  operate  the  site’s  entity  generator;  one  person 
to  monitor/work  network  status;  and  one  person  to  operate  the  2-D/3-D  visualization  device  for  test 
confirmations. 

4.6.5.4  Test  Conduct.  Time  was  often  lost  during  test  conduct  because  of  software  and  hardware 
problems,  scheduling  misinformation,  and/or  telephone  conference  difficulties.  Sites  need  to  provide 
a  dedicated  test  team  to  support  testing.  As  the  STOW-E  demonstration  neared,  more  sites  appar¬ 
ently  came  to  this  conclusion  since  sufficient  personnel  became  available  and,  under  most  circum¬ 
stances,  they  were  the  same  personnel  each  time.  Each  site  must  take  the  time  to  read  and  under¬ 
stand  the  test  plan/procedures.  A  lot  of  time  was  wasted  responding  to  questions  when  the  answers 
were  already  in  the  test  plan/procedures  document. 
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4.6.5.5  Test  Summary.  All  planned  testing  was  accomplished  in  some  form  or  another.  Addi¬ 
tional  tests  could  have  been  planned  and  might  certainly  have  been  appropriate  if  the  schedule  had 
not  been  so  compressed,  if  more  equipment  had  been  specifically  earmarked  for  testing,  and  if  more 
personnel  resources  had  been  available  to  support  the  additional  tests. 

While  the  use  of  trouble  reports  was  an  excellent  procedure,  their  usefulness  depended,  to  a  great 
extent,  on  the  attitude  of  the  cited  party.  Those  open  to  constructive  criticism  considered  the  proce¬ 
dure  a  valuable  resource,  took  appropriate  corrective  action,  and  tended  to  perform  well  throughout 
the  STOW-E  project.  Those  who  resented  externally  generated  TRs  often  had  difficulty  at  the  inte¬ 
grated  “system”  level  over  the  WAN. 

When  STOW-E  ended,  over  50  trouble  reports  remained  unaddressed.  Future  STOW  events 
should  have  a  rigid  requirement  that  all  deficiencies  cited  in  a  TR  be  corrected  before  a  site  is  per¬ 
mitted  to  continue  its  participation  in  WAN  testing. 


56 


5.0  ACRONYMS  AND  ABBREVIATIONS 

2-D 

Two-dimensional 

3-D 

Three-dimensional 

AAR 

After-Action  Review 

AAW 

Anti- Air  Warfare 

ACM 

Air  Combat  Maneuvering 

ACMI 

Air  Combat  Maneuvering  Instrumentation 

ACTD 

Advanced  Concepts  Technical  Demonstration 

AD 

Air  Defense 

ADS 

Advanced  Distributed  Simulation 

AFB 

Air  Force  Base 

AG 

Application  Gateway 

AIM 

Air  Intercept  Missile 

AIRNET 

Air  Network 

AIS 

Aircraft  Instrumentation  Subsystem 

AISI 

Aircraft  Instrumentation  Subsystem  Internal 

AIU 

Advanced  Interface  Unit 

ARPA 

Advanced  Research  Projects  Agency 

ATU 

Advanced  Translator  Unit 

AVTB 

Aviation  Test  Bed 

BATT 

Basic  Air  Tactics  Trainer 

BBN 

Bolt,  Beranek  and  Newman 

BBS 

Brigade/Battalion  Battle  Simulation 

BDA 

Battle  Damage  Assessment 

BFTT 

Battle  Force  Tactical  Trainer 

BLUFOR 

Blue  Forces 

BODAS 

Brigade  Operations  Display  and  AAR  System 

BRT 

Bandwith-Demand  Reduction  Techniques 

BTF 

Battalion  Task  Force 

CAP 

Corrective  Action  Point 

CCS 

Control  and  Computation  Subsystem 

CGF 

Computer-Generated  Forces 

CMS 

Communications  security  Material  Systems 

CMT 

Critical  Mobile  Targets 

CMTC 

Combat  Maneuver  Training  Center 

CMTC-IS 

Combat  Maneuver  Training  Center  -  Instrumentation  System 

CN 

Concentrator  Node 

CNA 

Center  for  Naval  Analysis 

CONUS 

Continental  United  States 

CPU 

Central  Processing  Unit 

CRT 

Cathode-Ray  Tube 

CS 

Combat  Support 

CSS 

Combat  Service  Support 

CU 

Comprehensive  Union 

DFAD 

Digital  Feature  Analysis  Data 

DI 

Dismounted  Infantry 

DIS 

Distributed  Interactive  Simulation 
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DIU 

DIS  Interface  Unit 

DLogger 

Data  Logger 

DMA 

Defense  Mapping  Agency 

DSI 

Defense  Simulation  Internet  (DIS  +  encrypted  data) 

DSN 

Defense  Switched  Network 

DTED 

Digital  Terrain  Elevation  Data 

ENMC 

Exercise  Network  Management  Center 

ES 

Entity  State 

ESPDU 

Entity  State  Protocol  Data  Unit 

EW 

Electronic  Warfare 

F-16 

Falcon  Star 

FCTCLANT 

Fleet  Combat  Training  Center  Atlantic 

ftp 

File  Transfer  Protocol 

FTS 

Federal  Telephone  System 

FV 

Functional  Validation 

GIS 

Geographic  Information  System 

GOI 

Grids  of  Interest 

GPS 

Global  Positioning  System 

GUI 

Graphical  User  Interface  . 

HDDS 

HyDy  Display  and  Debriefing  Subsystem 

HF 

High  Frequency 

HOTAS 

Hands  on  Throttle  and  Stick 

HPTD 

High  Performance  Tape  Drive 

HVUCAP 

High  Value  Unit  Combat  Air  Patrol 

HyDy 

Highly  Dynamic 

ID 

Identification  Number 

IDA 

Institute  for  Defense  Analysis 

IFOR 

Intelligent  Forces 

INES 

Improved  Performance  Network  Encryption  System  (Motorola) 

IP 

Internet  Protocol 

ITD 

Interim  Terrain  Data 

iTIN 

integrated  Triangular  Irregular  Networks 

LADS 

Loral  Advanced  Distributed  Simulation 

LAN 

Local  Area  Network 

LN 

Link  Node 

LOS 

Line  of  Sight 

LU 

Local  Union 

Mbps 

Megabits  per  second 

MCAS 

Marine  Corps  Air  Station 

MCC 

Management  Command  and  Control  console 

MFS 

Manned  Flight  Simulator 

MILES 

Multiple  Integrated  Laser  Engagement  System  II 

MOA 

Memorandum  of  Agreement 

MoDSAF 

Modulated  Semi-Automated  Forces 

MTBF 

Mean  Time  Between  Failure 

MUTTS 

Multi-Unit  Tactical  Training  System 

NAWC-AD 

Naval  Air  Weapons  Center  -  Aircraft  Division 

NCCOSC 

Naval  Command,  Control  and  Ocean  Surveillance  Center 
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NCS 

NOC 

NOFORN 

NRaD 

NSA 

NSC 

NTC 

NTCS-A 

NUWC 

OPFOR 

PDU 

PICA 

POC 

POP 

pps 

PVD 

QED 

RAF 

ROI 

SAF 

SAFOR 

SAM 

SAWE 

SE 

SE 

SEAF 

SEI 

SGI 

SIMNET 

SIT 

SLF 

Soar 

SOI 

SOP 

SP 

SSIT 

STOW-E 

TACCSF 

TACTRAGRULANT 

TACTS 

TAF 

TDB 

TEC 

TIN 

TIS 

TOC 

TR 


Net  Control  Station 
Network  Operations  Center 
No  Foreign 

NCCOSC  RDT&E  Division 

National  Security  Agency 

National  Simulation  Center,  Ft.  Leavenworth,  KS 

Naval  Training  Center 

Naval  Tactical  Command  System  -  Afloat 

Naval  Underwater  Warfare  Center 

Opposing  Forces 

Protocol  Data  Unit 

Protocol  Independent  Compression  Algorithum 

Point  of  Contact 

Persistent  Object  Protocol 

packets  per  second 

Plan  View  Display 

Quiescent  Entity  Determination 

Royal  Air  Force 

Regions  of  Interest 

Semi-Automated  Forces  (simulator) 

Semi-Automated  Forces 

Surface-to-Air  Missile 

Simulated  Area  Weapons  Effects 

Summary  Entity 

Synthetic  Environment 

STOW-E  Evaluation  and  Analysis  Facility 

Systems  Engineering  and  Integration 

Silicon  Graphics,  Incorporated 

Simulation  Network 

System  Integration  Test 

Standard  Linear  Format 

Artificial  intelligence  project  charged  with  developing  real-time  aggressor 

simulation 

Sphere  of  Influence 

Standard  Operating  Procedure 

Stream  Protocol 

Subsystem  Integration  Test 

Synthetic  Theater  of  War  -  Europe 

Theater  Air  Command  and  Control  Simulaton  Facility 

Tactical  Training  Group  Atlantic 

Tactical  Air  crew  Combat  Training  System 

Training  Analysis  Feedback  Facility 

Terrain  Database 

Topographic  Engineering  Center 

Triangular  Irregular  Network 

Tracking  Instrumentation  Subsystem 

Tactical  Operation  Center 

Trouble  Report 
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UCF 

University  of  Central  Florida 

UHF 

Ultrahigh  Frequency 

UO 

Uninstantiated  Object 

USAF 

United  States  Air  Force 

USAREUR 

United  States  Army,  Europe 

VHF 

Very  High  Frequency 

VME 

Versa  Modula  Europa  (bus  architecture  for  card  cages  in  AIU) 

VTC 

Video  Teleconferencing 

WAN 

Wide  Area  Network 

WISSARD 

What  If  Simulation  Systems  for  Research  and  Development 

WPC 

Warrior  Preparation  Center 
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